Re: [Chicken-users] compiling 32bit chicken on x86_64
Here it is: make -f Makefile.linux32 all make[1]: Entering directory `/home/daishi/src/chicken-3.2.0' gcc -m32 -shared \ -o libchicken.so library.o eval.o data-structures.o extras.o lolevel.o utils.o tcp.o srfi-1.o srfi-4.o srfi-13.o srfi-14.o srfi-18.o srfi-69.o posixunix.o regex.o scheduler.o profiler.o stub.o match.o runtime.o pcre/pcre_compile.o pcre/pcre_config.o pcre/pcre_dfa_exec.o pcre/pcre_exec.o pcre/pcre_fullinfo.o pcre/pcre_get.o pcre/pcre_globals.o pcre/pcre_info.o pcre/pcre_maketables.o pcre/pcre_newline.o pcre/pcre_ord2utf8.o pcre/pcre_refcount.o pcre/pcre_study.o pcre/pcre_tables.o pcre/pcre_try_flipped.o pcre/pcre_ucp_searchfuncs.o pcre/pcre_valid_utf8.o pcre/pcre_version.o pcre/pcre_xclass.o pcre/pcre_chartables.o apply-hack.x86.o -lm -ldl /usr/bin/ld: cannot find -lgcc_s_32 collect2: ld returned 1 exit status make[1]: *** [libchicken.so] Error 1 make[1]: Leaving directory `/home/daishi/src/chicken-3.2.0' make: *** [all] Error 2 I'm not sure if it's a chicken issue... Best, Daishi At Wed, 29 Oct 2008 15:50:28 +0100, felix winkelmann wrote: > > On Wed, Oct 29, 2008 at 3:33 PM, Daishi Kato <[EMAIL PROTECTED]> wrote: > > Hi, > > > > Has anybody tried compiling 32bit chicken on x86_64? > > I made a special Makefile, but giving me an error. > > I'm totally not sure if this is the right way or not. > > Thanks for any comments. > > Can you give us the error message? > > > cheers, > felix > > ** > XREA.COM -Free Web Hosting- > http://www.xrea.com/ > ** ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
Actually, I think it would be nice to have a tool that can automatically create a custom Chicken shared library that only includes the units that user specifies, and perhaps that can also statically link eggs to that library. For example, if I want to deploy a standalone application that does not use the regex and tcp units, but uses matchable and filepath, this hypothetical tool would be able to create a Chicken library that includes statically compiled syntax-case, matchable and filepath, but no regex or tcp units. What do people think about this? -Ivan Peter Bex <[EMAIL PROTECTED]> writes: > I think Ivan is not suggesting _adding_ this to core, but rather > _replacing_ what we have in core with this. In total, this should > have the net effect of adding nothing (though I don't know how big > both libraries are). ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
On Wed, 29 Oct 2008, Peter Bex wrote: On Wed, Oct 29, 2008 at 11:03:30AM +0100, felix winkelmann wrote: On Wed, Oct 29, 2008 at 9:04 AM, Ivan Raikov <[EMAIL PROTECTED]> wrote: Hi all, I have been meaning to port the Haskell FilePath library to Chicken, because I find its API to be quite elegant and better organized than the existing file name manipulation routines in Chicken. This discussion has prompted me to create the filepath egg, which is an almost verbatim transliteration of the Haskell code, with a few Chicken-specific idioms here and there. I have included a flag parameter, which can be used to enable "Posix" mode or "Windows" mode for path name parsing and manipulation. The Windows mode supports weird things like UNC names and is aware of the DOS reserved names (CON, PRN, etc). I would appreciate it if people look at it, as I would like to see some variant of this API supersede the existing Chicken path manipulation stuff. That library looks useful - nice port, Ivan. I would keep these things in extensions, though. There is already too much stuff in the core (I know I keep repeating this, but I'm really concerned about it). I think Ivan is not suggesting _adding_ this to core, but rather _replacing_ what we have in core with this. In total, this should have the net effect of adding nothing (though I don't know how big both libraries are). filepath is fairly large. canonical-path and friends, together, are tiny. they are not addressing the same set of issues, regardless. again: canonical-path does not do existence checking. it is not meant to. it is intended to create localised canonical forms of a path in any representation as an aid to installation and naming portability. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] improved inlining
Hi Felix. Excellent move! I can confirm that inlining is often the key to widen performance bottle necks. And if I understand your modification correctly, it might even allow to inline functions from the chicken "core" if one generates suitable inline files. But let's start by collecting some experiences with the easier uses of inlining, e.g. inlining of code from extensions. Ciao Sven P.S. The resulting chicken (after clean and confclean) is not usable: > chicken Error: unbound variable: ##compiler#initialize-compiler ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] s11n and tinyclos
On Fri, Oct 24, 2008 at 7:43 AM, Shawn Rutledge <[EMAIL PROTECTED]> wrote: >> >> Or anything that has a global identity, beyond built-in. Need some kind of >> '(remain )' to designate existing "root" objects, i.e. objects that >> will exist when the de-serialization occurs. How to handle the "root" >> dependency is unspecified. > > That was a long time ago... now I just found myself wanting to try > this too. The behavior is different: > > #;1> (use s11n) > ; loading /usr/lib64/chicken/3/s11n.so ... > #;2> (use tinyclos) > ; loading /usr/lib64/chicken/3/tinyclos.scm ... > ; loading /usr/lib64/chicken/3/tinyclos-base.so ... > #;3> (define-class () (element)) > #;4> (define-method (initialize (thing ) (element )) > (slot-set! thing 'element element)) > #;5> (let ((port (open-output-file "~/thing.txt")) > (thing (make "allo"))) > (serialize thing port) > (close-output-port port)) > Error: (serialize) unable to serialize object - unable to serialize > procedure (no table entry found): # This means that no entry is stored in the local "procedure table". What's the output of "chicken -version"? Does it show "ptables"? cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: improved inlining
I forgot to add that "-debug i" will show a lot of useful output, in case you want to experiment. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] improved inlining
Hi!
I have added some inlining improvements to the trunk that
might be of interest: together with a bit of compiler cleanup,
inlining has been made more aggressive (a higher default setting
for "inline-limit") and a new compilation mode ("local") has been
added. "local" is what gambit calls "block": it assumes the toplevel
variables in the current compilation unit are not changed outside
of the current one. Note that this is weaker than our "block" mode, which
effectively hides all toplevel variables, allowing to drop definitions
entirely if unused. In this mode, toplevel definitions
can be inlined, if they are assigned only once.
To enable "local" mode, use the "-local" option. Note that
you still have to enable inlining explicitly with "-inline". The
optimization levels have been changed so that -O3 enables
-local -inline (but is still safe) and -O4 adds "-unsafe".
The benchmark suite has been improved (there is a toplevel
"bench" target now) and some tests from the shootout have been
added. The performance gains from local mode vary between
pathetic and dramatic - it is particularly beneficial when you have
many small exported accessor functions, for example.
The new option "-inline-global" allows cross-module inlining by
making functions defined in other compilation units available
for inlining (for units used via "(declare (uses ...))" or extensions
loaded via "(require-extension ...)" or "(require-library ...)").
The way this works is that yet another option "-emit-inline-file FILENAME"
writes inlining-candidates in the internal compiler tree format to a file and
the compiler (with -inline-global) looks for a suitable file named
".inline".
These inline files can be installed together with import libs and
compiled extensions in
the local extension repository.
So it goes somewhat like this:
% csc foo.scm -emit-inline-file foo.inline # -emit-inline-file
implies "-inline -local"
% csc bar.scm -inline-global # uses "foo", somehow
This facility hasn't been tested a lot, so one will have to experiment a
little. As chicken applications tend to use a growing number of extensions,
getting cross-module inlining to work effectively can significantly improve
performance. Any feedback is greatly appreciated.
cheers,
felix
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] compiling 32bit chicken on x86_64
On Wed, Oct 29, 2008 at 3:33 PM, Daishi Kato <[EMAIL PROTECTED]> wrote: > Hi, > > Has anybody tried compiling 32bit chicken on x86_64? > I made a special Makefile, but giving me an error. > I'm totally not sure if this is the right way or not. > Thanks for any comments. Can you give us the error message? cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Repository mirror
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29 Oct 2008, at 2:06 pm, Peter Bex wrote: Many thanks again, Alaric, for providing the server space! This is great! Thanks Alaric! Since my Life Failure of the past year or so seems to have precluded me doing any actual programming that doesn't reap an immediate profit, I'm happy to be doing *something* for the community ;-) ABS - -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/?author=4 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkkIdsIACgkQRgz/WHNxCGrDeACfXeUks68IXDf1I+VE/TLTMqDy 6rcAn0hrXn1aLDxJ8e0OVrIazbth4jUj =1qjp -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] compiling 32bit chicken on x86_64
Hi, Has anybody tried compiling 32bit chicken on x86_64? I made a special Makefile, but giving me an error. I'm totally not sure if this is the right way or not. Thanks for any comments. Best, Daishi % diff Makefile.linux Makefile.linux32 30c30 < ARCH = $(shell sh config-arch.sh) --- > ARCH = x86 34c34,35 < C_COMPILER_OPTIONS = -fno-strict-aliasing -DHAVE_CHICKEN_CONFIG_H --- > C_COMPILER_OPTIONS = -fno-strict-aliasing -DHAVE_CHICKEN_CONFIG_H -m32 > LINKER_OPTIONS = -m32 ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Repository mirror
On Wed, Oct 29, 2008 at 03:00:27PM +0100, felix winkelmann wrote: > Hello! > > Thanks to Alaric and Mario, we have a mirror site for SVN access now: > > http://chicken.kitten-technologies.co.uk/ > > The repository is updated hourly and allows read-only access, in > case there are problems with galinha (or it's connection to the > 'net). > > The "chicken-install" program has been extended to try several > download locations, and has been preconfigured to take the > new mirror site into account (trunk). > > Many thanks again, Alaric, for providing the server space! This is great! Thanks Alaric! -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth pgpoQsCzSWos4.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Repository mirror
Hello! Thanks to Alaric and Mario, we have a mirror site for SVN access now: http://chicken.kitten-technologies.co.uk/ The repository is updated hourly and allows read-only access, in case there are problems with galinha (or it's connection to the 'net). The "chicken-install" program has been extended to try several download locations, and has been preconfigured to take the new mirror site into account (trunk). Many thanks again, Alaric, for providing the server space! cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
On Wed, Oct 29, 2008 at 11:43 AM, Peter Bex <[EMAIL PROTECTED]> wrote: >> >> I would keep these things in extensions, though. There is already too much >> stuff in the core (I know I keep repeating this, but I'm really concerned >> about >> it). > > I think Ivan is not suggesting _adding_ this to core, but rather > _replacing_ what we have in core with this. In total, this should > have the net effect of adding nothing (though I don't know how big > both libraries are). The current stuff is relatively minimal, compared to the full filepath library. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
On Wed, Oct 29, 2008 at 11:03:30AM +0100, felix winkelmann wrote: > On Wed, Oct 29, 2008 at 9:04 AM, Ivan Raikov <[EMAIL PROTECTED]> wrote: > > > > Hi all, > > > > I have been meaning to port the Haskell FilePath library to > > Chicken, because I find its API to be quite elegant and better > > organized than the existing file name manipulation routines in > > Chicken. This discussion has prompted me to create the filepath egg, > > which is an almost verbatim transliteration of the Haskell code, with > > a few Chicken-specific idioms here and there. I have included a flag > > parameter, which can be used to enable "Posix" mode or "Windows" > > mode for path name parsing and manipulation. The Windows mode supports > > weird things like UNC names and is aware of the DOS reserved names > > (CON, PRN, etc). I would appreciate it if people look at it, as I > > would like to see some variant of this API supersede the existing > > Chicken path manipulation stuff. > > > > That library looks useful - nice port, Ivan. > > I would keep these things in extensions, though. There is already too much > stuff in the core (I know I keep repeating this, but I'm really concerned > about > it). I think Ivan is not suggesting _adding_ this to core, but rather _replacing_ what we have in core with this. In total, this should have the net effect of adding nothing (though I don't know how big both libraries are). Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth pgpvY0rR91YHG.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
On Wed, Oct 29, 2008 at 9:04 AM, Ivan Raikov <[EMAIL PROTECTED]> wrote: > > Hi all, > > I have been meaning to port the Haskell FilePath library to > Chicken, because I find its API to be quite elegant and better > organized than the existing file name manipulation routines in > Chicken. This discussion has prompted me to create the filepath egg, > which is an almost verbatim transliteration of the Haskell code, with > a few Chicken-specific idioms here and there. I have included a flag > parameter, which can be used to enable "Posix" mode or "Windows" > mode for path name parsing and manipulation. The Windows mode supports > weird things like UNC names and is aware of the DOS reserved names > (CON, PRN, etc). I would appreciate it if people look at it, as I > would like to see some variant of this API supersede the existing > Chicken path manipulation stuff. > That library looks useful - nice port, Ivan. I would keep these things in extensions, though. There is already too much stuff in the core (I know I keep repeating this, but I'm really concerned about it). cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
Hi all, I have been meaning to port the Haskell FilePath library to Chicken, because I find its API to be quite elegant and better organized than the existing file name manipulation routines in Chicken. This discussion has prompted me to create the filepath egg, which is an almost verbatim transliteration of the Haskell code, with a few Chicken-specific idioms here and there. I have included a flag parameter, which can be used to enable "Posix" mode or "Windows" mode for path name parsing and manipulation. The Windows mode supports weird things like UNC names and is aware of the DOS reserved names (CON, PRN, etc). I would appreciate it if people look at it, as I would like to see some variant of this API supersede the existing Chicken path manipulation stuff. -Ivan Vincent Manis <[EMAIL PROTECTED]> writes: > I strongly disagree with this particular recommendation. Sometimes I > have code running on Unix that manipulates Windows file names > (thanks to VirtualBox, that's something I want to do more often, > these days). I recommend a design that has a flag with settings such > as `this is a Windows name', `this is a Unix name', and a default > setting of `this is a name for the OS I'm currently on', which can > certainly work the way Peter suggests. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
