[Chicken-users] chicken-hosted stalin
Hi! A stalin egg has been added to the repository that provides a slightly modified version of Jeffrey Mark Siskinds Stalin Scheme-C compiler, compiled with chicken. Even though the compiler is even slower than the original one, it compiles (the compiler itself) faster and uses less resources (takes for example around 1 1/2 hours on a 512mb Mac Mini (ppc)). It also has a few extensions (more character escape sequences in string literals and SRFI-0 support (cond-expand)). More information can be found here: http://chicken.wiki.br/stalin cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-hosted stalin
felix winkelmann scripsit: Even though the [chicken-stalin] compiler is even slower than the original one, it compiles (the compiler itself) faster [...]. This is indecipherable. The purpose of a compiler is to compile; if chicken-stalin compiles the Stalin source code faster than native stalin does, in what sense is it also slower? And if chicken-stalin *is* slower, what is the point of compiling Stalin with csc, since a program that is inherently as slow as Stalin should presumably be compiled with the compiler that produces the fastest executables, viz. native stalin? Also, I'm not clear how much use Stalin is in the Chicken environment, given its severe restrictions on input language. If Stalin could be front-ended with an R5RS macro expander, and if enough bootstrap procedures could be provided that it could understand a larger fraction of Chicken Scheme, then it would indeed be useful to have as an alternative compiler. http://chicken.wiki.br/stalin The link to the Stalin manual is to stalin1html, which is broken. Plausible alternatives like stalin.1.html, stalin1.html, stalin.1, and stalin1 also don't work. -- Clear? Huh! Why a four-year-old child John Cowan could understand this report. Run out [EMAIL PROTECTED] and find me a four-year-old child. I http://www.ccil.org/~cowan can't make head or tail out of it. --Rufus T. Firefly on government reports ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-hosted stalin
On Jan 22, 2008 3:45 PM, John Cowan [EMAIL PROTECTED] wrote: felix winkelmann scripsit: Even though the [chicken-stalin] compiler is even slower than the original one, it compiles (the compiler itself) faster [...]. This is indecipherable. The purpose of a compiler is to compile; if chicken-stalin compiles the Stalin source code faster than native stalin does, in what sense is it also slower? And if chicken-stalin *is* slower, what is the point of compiling Stalin with csc, since a program that is inherently as slow as Stalin should presumably be compiled with the compiler that produces the fastest executables, viz. native stalin? chicken-stalin can be built on systems that are too weak to build the regular stalin, it also runs probably on more platforms. I think this is useful. Due to the reduced turnaround times and the much richer runtime environment, one can actually debug and enhance the system (much more so as the original one). Also, I'm not clear how much use Stalin is in the Chicken environment, given its severe restrictions on input language. If Stalin could be front-ended with an R5RS macro expander, and if enough bootstrap procedures could be provided that it could understand a larger fraction of Chicken Scheme, then it would indeed be useful to have as an alternative compiler. You have to see for yourself whether you find it useful. It is possible to mix chicken and stalin code, so one could conceive trying to get the best of both worlds (partially fast code and partically using a rich and dynamic runtime environment). Adding macros and more compiler language support could be done, though. So this is a start. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-hosted stalin
felix winkelmann scripsit: chicken-stalin can be built on systems that are too weak to build the regular stalin, it also runs probably on more platforms. I think this is useful. Due to the reduced turnaround times and the much richer runtime environment, one can actually debug and enhance the system (much more so as the original one). Fair enough. I'm still not clear on whether it is actually slower or faster, though, or perhaps slower in general but faster when compiling Stalin, or what. You have to see for yourself whether you find it useful. It is possible to mix chicken and stalin code, so one could conceive trying to get the best of both worlds (partially fast code and partically using a rich and dynamic runtime environment). Adding macros and more compiler language support could be done, though. So this is a start. Also fair enough. -- John Cowan [EMAIL PROTECTED] http://www.ccil.org/~cowan Most languages are dramatically underdescribed, and at least one is dramatically overdescribed. Still other languages are simultaneously overdescribed and underdescribed. Welsh pertains to the third category. --Alan King ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-hosted stalin
John Cowan wrote: felix winkelmann scripsit: Even though the [chicken-stalin] compiler is even slower than the original one, it compiles (the compiler itself) faster. This is indecipherable. I was wondering too what is faster or slower than what! Chichen compiling Stalin to C, vs. Stalin compiling Stalin to C? Gcc compiling Chicken-compiled Stalin to executable, vs. gcc compiling Stalin-compiled Stalin to executable? Chicken-compiled Stalin compiling user code to C, vs. Stalin-compiled Stalin compiling user code to C? I'm probably missing some combination too... LOL Tobia ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-hosted stalin
On Jan 23, 2008 9:09 AM, John Cowan [EMAIL PROTECTED] wrote: felix winkelmann scripsit: Compilation of Scheme with Stalin takes extremely long. The chicken-compiled Stallin is smaller and doesn't stress gcc so much, but is (naturally) even slower than the original Stalin, which means slow compiling Scheme to C. Well, that's what I expected. But then what is the meaning of saying that there are faster turnaround times for chicken-stalin than for native stalin? I think the relevant point is that there are faster turnaround times for hacking Stalin itself. This is very important, because Stalin is minimal to the point of being unusable, and so a lot of hacking is needed. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
On 6/5/07, Brandon Van Every [EMAIL PROTECTED] wrote: If Scheme were a mental disorder, it would be ADD. Brilliant! I have to save this for future generations. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
On 6/4/07, Brandon Van Every [EMAIL PROTECTED] wrote: Reading this thread, all I can say is man what a bunch of goofy noodlers you are! :-) I can't even fathom the practical motivation to do any of this, seeing as Stalin is the most user unfriendly and unsupported Scheme distribution out there. Where is Stalin's wiki, bug tracker, source code repository, extensions repository, mailing list, and user community? The question isn't how you would use Stalin with Chicken, but whether anyone uses Stalin at all. applause (Goofy noodlers: I like that!) cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
On 6/5/07, John Cowan [EMAIL PROTECTED] wrote: Brandon Van Every scripsit: Speed, to the exclusion of all other considerations, is not the real world. I can understand compiling portable Scheme code under any 2 different compilers. I cannot fathom trying to get such code to interoperate. This thread reads like a Frankenstein support nightmare. Developing code under Chicken is fairly straightforward; developing code under Stalin is painful in the extreme. It therefore is plausible to have a Stalin-compatible library for Chicken that allows one to develop code that Stalin can handle after it is fully debugged under Chicken. You can then gain the advantages of Stalin's massive optimizations to gain execution speed. BTW, has anyone gotten stalin to work lately? I ran my 512mb Athlon for the whole night and was not able to compile stalin 0.11 (gcc 4.1.2). cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
felix winkelmann schrieb: On 6/5/07, John Cowan [EMAIL PROTECTED] wrote: Brandon Van Every scripsit: Speed, to the exclusion of all other considerations, is not the real world. I can understand compiling portable Scheme code under any 2 different compilers. I cannot fathom trying to get such code to interoperate. This thread reads like a Frankenstein support nightmare. Developing code under Chicken is fairly straightforward; developing code under Stalin is painful in the extreme. It therefore is plausible to have a Stalin-compatible library for Chicken that allows one to develop code that Stalin can handle after it is fully debugged under Chicken. You can then gain the advantages of Stalin's massive optimizations to gain execution speed. BTW, has anyone gotten stalin to work lately? I ran my 512mb Athlon for the whole night and was not able to compile stalin 0.11 (gcc 4.1.2). I didn't compile it myself, but it is in the universe repos of feisty fawn. It's version 0.11-1 so basically yes, i am able to work with it. Greets David ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
Tue, 05 Jun 2007 13:06:29 +0300, danmbox wrote: BTW, has anyone gotten stalin to work lately? I ran my 512mb Athlon for the whole night and was not able to compile stalin 0.11 (gcc 4.1.2). Same here with a 768 MB box. The machine tries to compile stalin.c but mostly trashes the swap space (strangely, since it's just a -O2 compilation). I wonder how much memory is needed to avoid swapping. Works for me: memtime gcc -o stalin -I./include -O3 -fomit-frame-pointer \ -fno-strict-aliasing -freg-struct-return stalin.c -L./include -lm -lgc 1263.35 user, 7.76 system, 1271.91 elapsed -- Max VSize = 1672KB, Max RSS = 544KB Max VSize and the gcc version might be the problem for some people. gcc --version gcc (GCC) 4.2.0 uname -a Linux 2.6.11.4 ... i686 i386 GNU/Linux Ciao Sven pgpcxW78xSEFK.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
On 6/4/07, John Cowan [EMAIL PROTECTED] wrote: Brandon Van Every scripsit: Speed, to the exclusion of all other considerations, is not the real world. I can understand compiling portable Scheme code under any 2 different compilers. I cannot fathom trying to get such code to interoperate. This thread reads like a Frankenstein support nightmare. Developing code under Chicken is fairly straightforward; developing code under Stalin is painful in the extreme. It therefore is plausible to have a Stalin-compatible library for Chicken that allows one to develop code that Stalin can handle after it is fully debugged under Chicken. You can then gain the advantages of Stalin's massive optimizations to gain execution speed. With no eggs. This is infrastructurally lame. Anyone who is that enamored with speed deserves what they get. Efforts would be better spent actually creating a community around Stalin and showing some leadership addressing its utter inadequacies. C'mon guys, if you want to develop with someone's FTP dump then you just don't appreciate what it takes to do software. Stalin properly exists as a research reference and nothing more. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
Brandon Van Every scripsit: This is infrastructurally lame. Anyone who is that enamored with speed deserves what they get. Efforts would be better spent actually creating a community around Stalin and showing some leadership addressing its utter inadequacies. C'mon guys, if you want to develop with someone's FTP dump then you just don't appreciate what it takes to do software. Stalin properly exists as a research reference and nothing more. Brandon, this is pure negativity, only one step up from Don't do that, it won't help me develop games on Windows. If Stalin compatibility scratches someone's itch or tickles their fancy, it'll get done. If not, it won't. In either case, you are better off spending your time achieving your objectives than trying to tell other people not to achieve theirs. -- John Cowanhttp://ccil.org/~cowan [EMAIL PROTECTED] 'Tis the Linux rebellion / Let coders take their place, The Linux-nationale / Shall Microsoft outpace, We can write better programs / Our CPUs won't stall, So raise the penguin banner of / The Linux-nationale. --Greg Baker ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] chicken and stalin
On 6/5/07, John Cowan [EMAIL PROTECTED] wrote: Brandon Van Every scripsit: This is infrastructurally lame. Anyone who is that enamored with speed deserves what they get. Efforts would be better spent actually creating a community around Stalin and showing some leadership addressing its utter inadequacies. C'mon guys, if you want to develop with someone's FTP dump then you just don't appreciate what it takes to do software. Stalin properly exists as a research reference and nothing more. Brandon, this is pure negativity, only one step up from Don't do that, it won't help me develop games on Windows. If Stalin compatibility scratches someone's itch or tickles their fancy, it'll get done. If not, it won't. In either case, you are better off spending your time achieving your objectives than trying to tell other people not to achieve theirs. This goes far beyond games on Windows. This is about people completely wasting their time on projects that, if they have no academic context, are completely worthless. I've gone bankrupt chasing nonsense. I have delusions of grandeur that I *might* save some young buck from his/her utter cluelessness in the face of industrial reality. I don't want to invoke Felix as having an opinion on this issue, but why do you think he rolls his eyeballs when R6RS comes up? I'll wager, because there's a huge chunk of people in Scheme-land that DON'T GET IT when it comes to practical reality. That's why Scheme sucks as far as standardization, why it remains a research rather than practical language for most of the computer industry, and why it fails to gain any relevance. Too many smart, tweaky people with no clue working on things that don't matter. If Scheme were a mental disorder, it would be ADD. I don't really believe in software as a playground. I believe in software that gets important things done. That's why I was willing to put 1 man year into the Chicken build system, a fairly dull task, and other people generally aren't. My build system is going to be here years from now, unless something substantially better than CMake comes along, which I don't expect to happen anytime soon. Whereas Chicken and Stalin compatibility libraries and interop will *NEVER* be here. Not in any sense beyond 1 person's irreproducible homebrew that breaks the 1st month they have to go get a real job. I've spent 3 years evaluating what counts in open source. THIS DOESN'T COUNT. This isn't even about the prowess of any particular author who wishes to take Chicken-Stalin on. As cynical as I am about what well-intentioned people can actually accomplish, the real issue is LOOK AT YOUR PARTNER. Stalin is the biggest joke from an open source support standpoint that I've ever seen. You're never going to get anything out of its author. His compiler is out there so that people can do what they like with it, without bugging him about it. It is a research reference implementation and nothing more. Great stuff if you're getting your PhD in compiler design; otherwise, worthless. Stalin's author knows that he's contributing to an academic corpus, the publish or perish crowd. He has NO INCENTIVE WHATSOEVER to pursue the practical industrial things that we pursue in the Chicken community. This pattern is abundant in the academic language research community. You will find it with the SML/NJ crowd as well, to a lesser degree. They make no bones about being academic guys, not open source community building guys. Felix's language leadership is very different from the academic average. Be thankful and avail yourself of it. Nobody can tell anyone what to do in open source. But I sure hope someone out there is capable of learning from other people chopping off their fingers, rather than chopping off their own. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
Dan Muresan scripsit: I think it's pretty well established that Stalin (and Gambit?) are faster than Chicken, but Chicken has a much better ecosystem (community, libraries etc). No dispute about any of that. P.S. All this talk of Stalin has made me curious; is there a page documenting Stalin's limitations / standard adherence? If it's just the lack of syntax-rules support, that can be worked around with the help of Alexpander. First, note that Stalin is an R4RS Scheme, so not only no syntax-rules, but also no eval, dynamic-wind, or multiple values. It's not clear to me whether () is true or false; R4RS allowed either behavior. Here are the relevant parts of the README: DEVIATIONS [from R4RS] 1. Unimplemented syntax: 4.2.6 Nested quasiquotation is not supported. appendix Macros 2. Unimplemented procedures: 6.5.5NUMERATOR DENOMINATOR RATIONALIZE MAKE-RECTANGULAR MAKE-POLAR REAL-PART IMAG-PART MAGNITUDE ANGLE 6.10.4 LOAD TRANSCRIPT-ON TRANSCRIPT-OFF 3. (1.1) Tail recursion optimization is done only on self calls. [Apparently no longer true with a recent enough gcc.] 4. (6.5) The following numeric data types are not supported: a. bignums: exact integers of arbitrary magnitude Furthermore, exact integer arithmetic can overflow without signaling an error and without yielding an inexact floating point number. b. ratios: exact non-integer rationals c. polar format complex numbers d. exact rectangular format complex numbers 5. It is not possible to access all of the underlying C scalar types. (This is not an incompatibility with R4RS but nonetheless important for other reasons.) a. No independent control over the float/double distinction. b. No long/short chars/ints/floats/doubles c. No unsigned chars/ints 6. (1.3.1) No R4RS compliance mode is provided. 7. Limitations of (6.5.6) STRING-NUMBER, (6.10.2) READ, and the source program: a. Can't parse largest negative number. b. Can't parse polar numbers with @. c. Can't parse rectangular numbers with i. d. Can't parse ratios with /. e. Can't parse numbers with embedded #. f. Can't parse exactness with #E and #I. g. Can't parse inexact numbers with mantissas where the digit string before the decimal point would overflow if read as an exact number, h. On Intel, SPARC, and SGI, the source program can't contain exact integer constants -536870912 or 536870911. On Intel and SPARC, the compiler will generate incorrect C code without warning. On SGI, the compiler might signal an exception or might generate incorrect C code without warning. On Alpha, the source program can't contain exact integer constants -2305843009213693952 or 2305843009213693951. The compiler will generate incorrect C code without warning. 8. (6.5.6) STRING-NUMBER doesn't accept the optional radix argument. 9. APPLY and CALL-WITH-CURRENT-CONTINUATION don't accept continuations or foreign procedures as their first argument. 10. (6.2) EQV? might return #T when given two procedures that can never be called. (BEGIN (DEFINE (F X) (LAMBDA () X)) (EQV? (F 1) (F 2))) == #T EQV? might return #T when given two fictitious pairs or degenerate vectors. (EQV? (CONS #T #T) (CONS #T #T)) == #T (EQV? (VECTOR #T) (VECTOR #T)) == #T 11. (6.5.5) =, , , =, = might not be transitive. 12. (6.5.6) STRING-NUMBER, READ, DISPLAY, and WRITE don't obey write/read invariance for inexact numbers. 13. (APPLY (LAMBDA X X) y) == y without checking that y is a list and without copying y. Furthermore, because of the way LIST is defined, (APPLY LIST X) doesn't copy X. 14. (6.10.1) Closing a port that has already been closed yields undefined behaviour rather than having no effect. EXTENSIONS Stalin extends R4RS in a number of ways: 1. New syntax: PRIMITIVE-PROCEDURE and FOREIGN-PROCEDURE. 2. New procedures: LIST-LENGTH, SUBLIST, SUB, LIST-APPEND, LIST-REVERSE, REF, LIST-SET!, REF!, LIST-FILL!, FILL!, LIST-COPY, STRING-UNINTERNED-SYMBOL, STRING-REVERSE, , , BITWISE-NOT, BITWISE-AND, BITWISE-OR, MAKE-DISPLACED-VECTOR, SUBVECTOR, VECTOR-APPEND, VECTOR-REVERSE, VECTOR-COPY, PANIC, POINTER?, INTEGER-STRING, INTEGER-INPUT-PORT, INTEGER-OUTPUT-PORT, and INTEGER-POINTER. 3. New data type: pointer. ZERO? can be used to check for null pointers (as well as null strings and null ports). INTEGER-POINTER can be used to convert an integer address to a pointer. INTEGER-STRING, INTEGER-INPUT-PORT, and INTEGER-OUTPUT-PORT can be used to convert an integer address to a string, input port, or output-port, respectively. 4. New variable: ARGV is bound to a vector of strings containing
Re: [Chicken-users] chicken and stalin
Bryan, I'd like to know from what perspective you are approaching this. Do you already have code written for Stalin that you need to interface to Chicken? Or are you interested in the optimizations Stalin does purely as a research problem and would like to see if they are applicable to Chicken? Do you have a need for speed in a particular application you've written or is this just a general question? The reason I ask is that if you're interested in this from a practical standpoint of speed up my application, and are looking at Stalin primarily because it's fast, then I would attack this from a different angle. Write your application in Chicken, profile it, then take the bottleneck or critical paths and 1) rewrite the algorithm; 2) disable safe mode, interrupts, etc.; 3) rewrite in C; 4) use the crunch egg; and so on.It all depends on the goals of your application; pure speed is the goal only in select domains. Oh, and premature optimization is the root of all evil. :) If you're looking at this more from a theoretical angle, or just for fun, then that's a different matter, and other people have mentioned some possibilities. Something interesting may come of it. On 6/4/07, bryan rasmussen [EMAIL PROTECTED] wrote: I guess (for me) what I was meaning was what are different ways that people might be using Stalin for doing parts of their C compilation, and how Chicken works with what comes out of Stalin compilation as first part. Second part, analysis of Chicken Scheme code to see what would be more optimized in Stalin. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
Well, I suppose it is a general question. Basically I have a big application made a few years ago, we (meaning myself and some partners) want to start it up again and add capabilities to it, this application was at the point in it where I know what I will want to do will require C because will need to write some low level stuff that should be optimized - I don't want to write in C (mainly because as a C programmer I am at best at maintenance level) so a language I find enjoyable that compiles to C is good, I decided to pick Chicken because while I am a Scheme newbie I often find the code relatively easy to understand and elegant (I've gone through SICP and have a good bit of functional programming). That Stalin was faster was interesting because some of the things I can see writing is for example providing drivers for Erlang in C, well the reason one writes a driver for Erlang in C (for example, via dryverl http://dryverl.objectweb.org/ ) is because it is a situation where performance and speed is critical Of course the things Brandon has said has made me reconsider, because the reason why I would consider doing anything with Stalin (speed) will not be trumped by the need I have above speed, being development time. That is to say the need for speed is a possible vague future optimization, I realize premature optimization is evil but I figure premature discussion of optimization can only be, at worst, slightly naughty. Cheers, Bryan On 6/5/07, Zbigniew [EMAIL PROTECTED] wrote: Bryan, I'd like to know from what perspective you are approaching this. Do you already have code written for Stalin that you need to interface to Chicken? Or are you interested in the optimizations Stalin does purely as a research problem and would like to see if they are applicable to Chicken? Do you have a need for speed in a particular application you've written or is this just a general question? The reason I ask is that if you're interested in this from a practical standpoint of speed up my application, and are looking at Stalin primarily because it's fast, then I would attack this from a different angle. Write your application in Chicken, profile it, then take the bottleneck or critical paths and 1) rewrite the algorithm; 2) disable safe mode, interrupts, etc.; 3) rewrite in C; 4) use the crunch egg; and so on.It all depends on the goals of your application; pure speed is the goal only in select domains. Oh, and premature optimization is the root of all evil. :) If you're looking at this more from a theoretical angle, or just for fun, then that's a different matter, and other people have mentioned some possibilities. Something interesting may come of it. On 6/4/07, bryan rasmussen [EMAIL PROTECTED] wrote: I guess (for me) what I was meaning was what are different ways that people might be using Stalin for doing parts of their C compilation, and how Chicken works with what comes out of Stalin compilation as first part. Second part, analysis of Chicken Scheme code to see what would be more optimized in Stalin. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
Hi Bryan, if you're looking for performance you might consider gambit: http://www.iro.umontreal.ca/~gambit/ It compiles to C, has a great debugger, and you should find people on the gambit mailing list to help you if you have questions. You might want to take a look at termite too: Termite is an Erlang-like distributed programming system written in Scheme. http://toute.ca/ But if you're looking for lots of libraries your should probably stick with chicken. Cheers, -- Pierre-Alexandre 2007/6/5, bryan rasmussen [EMAIL PROTECTED]: Well, I suppose it is a general question. Basically I have a big application made a few years ago, we (meaning myself and some partners) want to start it up again and add capabilities to it, this application was at the point in it where I know what I will want to do will require C because will need to write some low level stuff that should be optimized - I don't want to write in C (mainly because as a C programmer I am at best at maintenance level) so a language I find enjoyable that compiles to C is good, I decided to pick Chicken because while I am a Scheme newbie I often find the code relatively easy to understand and elegant (I've gone through SICP and have a good bit of functional programming). That Stalin was faster was interesting because some of the things I can see writing is for example providing drivers for Erlang in C, well the reason one writes a driver for Erlang in C (for example, via dryverl http://dryverl.objectweb.org/ ) is because it is a situation where performance and speed is critical Of course the things Brandon has said has made me reconsider, because the reason why I would consider doing anything with Stalin (speed) will not be trumped by the need I have above speed, being development time. That is to say the need for speed is a possible vague future optimization, I realize premature optimization is evil but I figure premature discussion of optimization can only be, at worst, slightly naughty. Cheers, Bryan On 6/5/07, Zbigniew [EMAIL PROTECTED] wrote: Bryan, I'd like to know from what perspective you are approaching this. Do you already have code written for Stalin that you need to interface to Chicken? Or are you interested in the optimizations Stalin does purely as a research problem and would like to see if they are applicable to Chicken? Do you have a need for speed in a particular application you've written or is this just a general question? The reason I ask is that if you're interested in this from a practical standpoint of speed up my application, and are looking at Stalin primarily because it's fast, then I would attack this from a different angle. Write your application in Chicken, profile it, then take the bottleneck or critical paths and 1) rewrite the algorithm; 2) disable safe mode, interrupts, etc.; 3) rewrite in C; 4) use the crunch egg; and so on.It all depends on the goals of your application; pure speed is the goal only in select domains. Oh, and premature optimization is the root of all evil. :) If you're looking at this more from a theoretical angle, or just for fun, then that's a different matter, and other people have mentioned some possibilities. Something interesting may come of it. On 6/4/07, bryan rasmussen [EMAIL PROTECTED] wrote: I guess (for me) what I was meaning was what are different ways that people might be using Stalin for doing parts of their C compilation, and how Chicken works with what comes out of Stalin compilation as first part. Second part, analysis of Chicken Scheme code to see what would be more optimized in Stalin. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] chicken and stalin
Hi, I was wondering about integration between Chicken and Stalin, has anyone ever done anything to use the two together in any way? Cheers, Bryan Rasmussen ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
On 6/4/07, bryan rasmussen [EMAIL PROTECTED] wrote: Hi, I was wondering about integration between Chicken and Stalin, has anyone ever done anything to use the two together in any way? What exactly do you mean with integration? cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
bryan rasmussen wrote: Hi, I was wondering about integration between Chicken and Stalin, has anyone ever done anything to use the two together in any way? 1. Stalin reads sexps, chicken writes sexps (or vice versa) 2. Develop with a subset of chicken, deploy with stalin 3. Separate processes with fork/exec or client/server ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
On 6/4/07, Sunnan [EMAIL PROTECTED] wrote: bryan rasmussen wrote: Hi, I was wondering about integration between Chicken and Stalin, has anyone ever done anything to use the two together in any way? 1. Stalin reads sexps, chicken writes sexps (or vice versa) You mean, chicken+stalin compiled code exchanges information, right? Sure, supported. ;-) 2. Develop with a subset of chicken, deploy with stalin A stalin-compat library? No problem. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
felix winkelmann wrote: A stalin-compat library? No problem. It wasn't so much a request as an example of what people can do. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
On 6/4/07, felix winkelmann [EMAIL PROTECTED] wrote: On 6/4/07, Sunnan [EMAIL PROTECTED] wrote: felix winkelmann wrote: A stalin-compat library? No problem. It wasn't so much a request as an example of what people can do. I was not suggesting to write such a thing. :-) Reading this thread, all I can say is man what a bunch of goofy noodlers you are! :-) I can't even fathom the practical motivation to do any of this, seeing as Stalin is the most user unfriendly and unsupported Scheme distribution out there. Where is Stalin's wiki, bug tracker, source code repository, extensions repository, mailing list, and user community? The question isn't how you would use Stalin with Chicken, but whether anyone uses Stalin at all. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
Hallo, On 6/4/07, Brandon Van Every [EMAIL PROTECTED] wrote: Reading this thread, all I can say is man what a bunch of goofy noodlers you are! :-) I can't even fathom the practical motivation to do any of this, seeing as Stalin is the most user unfriendly and unsupported Scheme distribution out there. Speed. -- -alex http://www.ventonegro.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken and stalin
Brandon Van Every scripsit: Speed, to the exclusion of all other considerations, is not the real world. I can understand compiling portable Scheme code under any 2 different compilers. I cannot fathom trying to get such code to interoperate. This thread reads like a Frankenstein support nightmare. Developing code under Chicken is fairly straightforward; developing code under Stalin is painful in the extreme. It therefore is plausible to have a Stalin-compatible library for Chicken that allows one to develop code that Stalin can handle after it is fully debugged under Chicken. You can then gain the advantages of Stalin's massive optimizations to gain execution speed. -- John Cowan [EMAIL PROTECTED] http://ccil.org/~cowan In the sciences, we are now uniquely privileged to sit side by side with the giants on whose shoulders we stand. --Gerald Holton ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
