Re: Chicken-setup redesign (was: Re: [Chicken-users] Re: getopt, getopt_long?)
On Fri, Jul 11, 2008 at 12:01 AM, Shawn Rutledge <[EMAIL PROTECTED]> wrote: > > I look at it this way: what is essential is the metadata, including > the enumeration of the files that are included along with what they > _are_. If I say "here are my source files, here are my documentation > files, and here are my examples" why shouldn't chicken-setup know what > to do with them by default? Or if you even leave those out, but have > a standard directory structure (src, doc and examples) chicken-setup > could make straightforward decisions based on that. So the minimum > requirement would be a metadata file containing the egg description > and category. Actually I would leave out documentation files, examples and installation of applications - just handle libraries and have the wiki page link to examples stored somewhere. The metadata on the other hand is already there (the "repository" file), and I have written a script (mostly untested) that takes a svn tree and generates eggs and a repository file containing all metadata (maintenance/create-repository.scm in the svn tree toplevel). > > Writing a separate setup script in addition to that should be > optional, and rare. I don't like all the duplication of information > with the current requirements for writing an egg. Yes, I understand. But there are always situations where building an extension can become arbitrarily complex. Here a procedural way (i.e. a script) must in the end be available. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: Chicken-setup redesign (was: Re: [Chicken-users] Re: getopt, getopt_long?)
On Thu, Jul 10, 2008 at 7:23 PM, Peter Bex <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 10, 2008 at 02:41:27PM +0200, Peter Bex wrote:
>> Of course, this would also require the possibility of loading a
>> particular version of a library. I propose this syntax:
>>
>> (require-library foo (bar 1.2) (qux 1))
>>
>> This requires the latest installed version of foo (whatever that is),
>> and version 1.2 of bar. From qux the latest installed minor version
>> with major version 1 is required (so, if you have 1.1 and 1.2 installed,
>> it will pick 1.2). These semantics match those of the 'versions' egg,
>> I think.
>
> On second thought, the syntax above is needlessly complex.
>
> (require-library foo bar-1.2 qux-1) is much more straightforward and
> maps _directly_ to the code in the 'versions' egg, too. It also reserves
> the "structured library names" like (bar ..) for future enhancements.
Indeed, the list structures are already used ("(srfi 1 2 3)", etc.). There
even is a "(version ...)" feature, but I forgot what it does (;-). The only
problem is searching for the highest sub-version, which will require
comparison of version files and obtaining directory listings. This will
have to happen at runtime and it would be unfortunate to make every
program depend on the posix unit.
cheers,
felix
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] thread makes csi eats lots of cpu
On Fri, Jul 11, 2008 at 3:16 AM, William Xu <[EMAIL PROTECTED]> wrote: > > It prints the first number 0, which is called before thread-sleep!. > After that, it'll wait for me to input something random(here, "what?"), > then it'll continute running the thread. On Linux this runs fine, but I'll check that (should I ever get a chance to hack some Scheme in the next days, which I doubt...). > > The other problem is that after running this thread, and even after it's > finished, csi starts to takes up to around 97% cpu usage!! on my dual > core macbook. Then I have to restart csi. When the counter reaches five, your thread goes into an endless loop. This will of course consume all CPU time. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: thread makes csi eats lots of cpu
oke, so youre on osx and its blocking from stdin... i was not aware of this. thank you. :) -elf On Fri, 11 Jul 2008, William Xu wrote: Elf <[EMAIL PROTECTED]> writes: You're running readline in csi, yes? That blocks the threads. I didn't install this egg. , | #;1> (use readline) | Error: (require) can not load extension: readline | | Call history: | | (use readline) | (##core#require-extension (quote readline)) | (begin (##sys#require (quote readline)) (##core#undefined)) | (##sys#require (quote readline)) | (quote readline) | (##core#undefined) | (##sys#require (quote readline))<-- ` ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: thread makes csi eats lots of cpu
Elf <[EMAIL PROTECTED]> writes: > You're running readline in csi, yes? That blocks the threads. I didn't install this egg. , | #;1> (use readline) | Error: (require) can not load extension: readline | | Call history: | | (use readline) | (##core#require-extension (quote readline)) | (begin (##sys#require (quote readline)) (##core#undefined)) | (##sys#require (quote readline)) | (quote readline) | (##core#undefined) | (##sys#require (quote readline))<-- ` -- William http://williamxu.net9.org Behind every great man, there is a woman -- urging him on. -- Harry Mudd, "I, Mudd", stardate 4513.3 ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] thread makes csi eats lots of cpu
You're running readline in csi, yes? That blocks the threads. -elf On Fri, 11 Jul 2008, William Xu wrote: Run the following program in csi: (use posix srfi-18) (thread-start! (let ((max 5) (i 0)) (letrec ((thunk (lambda () (when (< i max) (print i) (thread-sleep! 1) (set! i (+ i 1))) (thunk thunk))) I'm expecting it to print 0-5. But the result is the following: , | #;2> # | #;3> 0 | | what? | Error: unbound variable: what? | #;3> 1 | 2 | 3 | 4 ` It prints the first number 0, which is called before thread-sleep!. After that, it'll wait for me to input something random(here, "what?"), then it'll continute running the thread. The other problem is that after running this thread, and even after it's finished, csi starts to takes up to around 97% cpu usage!! on my dual core macbook. Then I have to restart csi. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Little fix in svnrevision.sh
Hello, I was compiling the hygienic Chicken then at some point a parser error was displayed. It was because the constant C_SVN_REVISION was empty, and I've noticed its value is generated from the "buildsvnrevision" file, which in turn is created by the script "svnrevision.sh". This script uses the svn command. But since the locale is configured to my native language, svn outputs in the current locale and the information can't be parsed. This issue was easily fixed by adding the line LANG="C" into the top of "svnrevision.sh". Maybe this can be useful to someone else who happens to be using a different locale than English and wants to compile Chicken. Thanks for working hard on this nice project, Alonso Andres ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: getopt, getopt_long?
On Thu, Jul 10, 2008 at 6:26 PM, William Xu <[EMAIL PROTECTED]> wrote: > I don't know if i understand correctly. If that means making each egg a > debian package, oh Jesus!! That'll spawn many debian eggs. And > considering there are that many linux distributions, it's a big burden.. > not to mention non-linux platforms. There are many Debian packages though in general. This is kindof like perl modules: do you expect to have a distro package or do you want to use the perl cpan code to automatically download and install a module? Most distros actually have a bunch of popular perl modules as packages, even though that's some work for them to maintain. (But I've still had to use cpan once in a while too... and I'm not even much of a perl developer, I just have had to download prerequisites for other packages that I wanted to use, occasionally.) Obviously it needs to be automated (the process should be the same for each egg, so that it can be automated), but actually getting it done could be the work of some interested Debian developer, rather than someone who thinks of it as a drudgery (which would be most people, I would think). Worse, on Debian and OpenMoko they like to have, in addition to the main binary package, a separate -dev package which has the headers, static libs and other stuff necessary for developing with the package, and a -doc package. Doing that for each egg seems like a lot of work too. But on a cell phone you don't want to install any more than you must, depending on what your interest is, to save space. I'm not sure if Debian people will mind if an egg also includes its docs though. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] thread makes csi eats lots of cpu
Run the following program in csi: (use posix srfi-18) (thread-start! (let ((max 5) (i 0)) (letrec ((thunk (lambda () (when (< i max) (print i) (thread-sleep! 1) (set! i (+ i 1))) (thunk thunk))) I'm expecting it to print 0-5. But the result is the following: , | #;2> # | #;3> 0 | | what? | Error: unbound variable: what? | #;3> 1 | 2 | 3 | 4 ` It prints the first number 0, which is called before thread-sleep!. After that, it'll wait for me to input something random(here, "what?"), then it'll continute running the thread. The other problem is that after running this thread, and even after it's finished, csi starts to takes up to around 97% cpu usage!! on my dual core macbook. Then I have to restart csi. -- William http://williamxu.net9.org The animals are not as stupid as one thinks -- they have neither doctors nor lawyers. -- L. Docquier ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: getopt, getopt_long?
"felix winkelmann" <[EMAIL PROTECTED]> writes: > I think chicken-setup should NOT duplicate functionality that > modern packaging tools provide. Dpkg and portage will always > do a better job at that, and it would be more worthwhile to push > for adoption of eggs into these packaging systems (which, IIRC, > Ivan already does with debianizing several eggs). I don't know if i understand correctly. If that means making each egg a debian package, oh Jesus!! That'll spawn many debian eggs. And considering there are that many linux distributions, it's a big burden.. not to mention non-linux platforms. -- William http://williamxu.net9.org You cannot shake hands with a clenched fist. -- Indira Gandhi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: getopt, getopt_long?
Felix, I agree that if we consider only the essentials needed by chicken-setup, is should be possible to simplify egg installation, but this is precisely what could be accomplished by isolating the semantics in a domain-specific language. The current chicken-setup is essentially a Scheme interpreter with some macros and procedures for compiling and installing files. There is no way, however, to separate the installation by phases, such as documentation installation, library installation, etc. You keep insisting that such support for installation phases is duplicating the functionality of package management tools, but that is not the case at all. Installation phases will help support binary packages, but would not replace their functionality. Instead of manually creating Debian and RPM packages, it would be much simpler if the egg format specified what are the make commands for compiling, and identified the different components of the egg (libraries, executables, tests, examples, documentation). The a Debian package creation tool could parse that information and generate the corresponding Debian rules and control file. I agree that dpkg and friends would probably do a better job at supporting multiple versions of the same egg, etc., so at present I don't see the need for incorporating such functionality in chicken-setup. But a domain-specific language that allows the specification of installation locations, phases, and so on, would provide a platform to experiment with such ideas in the future. -Ivan "felix winkelmann" <[EMAIL PROTECTED]> writes: > Allow me a slight rant... > > chicken-setup has served us well, but now has mutated into a large > intricate mess. There has been a rewrite a while ago, but the messiness > is still there, partly because a tool like chicken-setup has to do so > many different things (file-system operations, extension handling, > HTTP download, build invocation, cross-compilation, etc.). I think the > only solution is to completely dump it and start from scratch. > > If we consider what we > essentially need (executing .setup scripts in a directory with the > egg sources), a backwards compatible API for executing the build > scripts it should be possible to reorganize the installation and > upgrading of eggs on a user's system in a simpler, better > maintainable and more transparent way. > > I have actually tried to isolate the pure .setup API (hygienic > branch, module setup-api.scm), but haven't got the time > or energy to start with such a project (insert the usual *HINT* > here - if someone would be willing to go for it, he/she could > rely on my eternal gratefulness). > > I think chicken-setup should NOT duplicate functionality that > modern packaging tools provide. Dpkg and portage will always > do a better job at that, and it would be more worthwhile to push > for adoption of eggs into these packaging systems (which, IIRC, > Ivan already does with debianizing several eggs). But a simple, > portable, library-only way of fetching a tarball via HTTP, extract, > build and install it, upgrade it if necessary and listing what's installed > would make all the extensions available to everybody (and that > would be enough, IMHO). A bare minimum to have access to all > those libraries and keep them up to date. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: Chicken-setup redesign (was: Re: [Chicken-users] Re: getopt, getopt_long?)
you can run chicken-setup in a way to compile an egg in-place in the current directory while you are developing it, right? rather than having to completely package it first, and without having to install it in its final location? I've been writing Makefiles for that, but figured there must be another way. chicken-setup -n (will run chicken-setup against any .setup files it sees in the local directory but will not install them. if you want them to be installed, it should be just 'chicken-setup') -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: Chicken-setup redesign (was: Re: [Chicken-users] Re: getopt, getopt_long?)
On Thu, Jul 10, 2008 at 3:08 PM, Elf <[EMAIL PROTECTED]> wrote: > however, > much of the actual compilation is *not* duplication, as extra bits like > linked libraries need to be specified. i can draft a proposal for how to Good point (my own eggs even do that). But it still maybe wouldn't have to be a complete, exact, brittle command for compiling, and there are many eggs that don't need to link libraries too. > fix things based on my own experiences both with the repo and with > chicken-setup, if people are interested. Sounds good. That reminds me of a dumb question I didn't get around to asking yet - you can run chicken-setup in a way to compile an egg in-place in the current directory while you are developing it, right? rather than having to completely package it first, and without having to install it in its final location? I've been writing Makefiles for that, but figured there must be another way. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: Chicken-setup redesign (was: Re: [Chicken-users] Re: getopt, getopt_long?)
oops, sorry about that. my 2c. chicken-setup is indeed overcomplex. i would propose a change not only to the chicken-setup and metadata files, but to the repo as well. as shawn said, there is a lot of duplication of data that should not be necessary. however, much of the actual compilation is *not* duplication, as extra bits like linked libraries need to be specified. i can draft a proposal for how to fix things based on my own experiences both with the repo and with chicken-setup, if people are interested. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: Chicken-setup redesign (was: Re: [Chicken-users] Re: getopt, getopt_long?)
Elf scripsit: > > Fascinating! Tell us more. -- John Cowan [EMAIL PROTECTED] http://ccil.org/~cowan Female celebrity stalker, on a hot morning in Cairo: "Imagine, Colonel Lawrence, ninety-two already!" El Auruns's reply: "Many happy returns of the day!" ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: Chicken-setup redesign (was: Re: [Chicken-users] Re: getopt, getopt_long?)
___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: Chicken-setup redesign (was: Re: [Chicken-users] Re: getopt, getopt_long?)
On Thu, Jul 10, 2008 at 09:25:21AM +0200, felix winkelmann wrote: > Allow me a slight rant... > > chicken-setup has served us well, but now has mutated into a large > intricate mess. There has been a rewrite a while ago, but the messiness > is still there, partly because a tool like chicken-setup has to do so > many different things (file-system operations, extension handling, > HTTP download, build invocation, cross-compilation, etc.). I think the > only solution is to > completely dump it and start from scratch. If we consider what we > essentially need (executing .setup scripts in a directory with the > egg sources), a backwards compatible API for executing the build > scripts it should be possible to reorganize the installation and > upgrading of eggs on a user's system in a simpler, better > maintainable and more transparent way. I look at it this way: what is essential is the metadata, including the enumeration of the files that are included along with what they _are_. If I say "here are my source files, here are my documentation files, and here are my examples" why shouldn't chicken-setup know what to do with them by default? Or if you even leave those out, but have a standard directory structure (src, doc and examples) chicken-setup could make straightforward decisions based on that. So the minimum requirement would be a metadata file containing the egg description and category. Writing a separate setup script in addition to that should be optional, and rare. I don't like all the duplication of information with the current requirements for writing an egg. And the install locations will be different for different systems sometimes, so they must not be hard-coded, and setup scripts should not be telling chicken-setup to violate those rules (like to put the documentation in the same directory as the compiled .so's... that's really messy). chicken-setup can be customized or parameterized to handle those cases. It's a system thing, not an egg thing. To play well with various Linux distros, it's a requirement to follow their rules about where packages' files are to be located. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: Chicken-setup redesign (was: Re: [Chicken-users] Re: getopt, getopt_long?)
On Thu, Jul 10, 2008 at 02:41:27PM +0200, Peter Bex wrote: > Of course, this would also require the possibility of loading a > particular version of a library. I propose this syntax: > > (require-library foo (bar 1.2) (qux 1)) > > This requires the latest installed version of foo (whatever that is), > and version 1.2 of bar. From qux the latest installed minor version > with major version 1 is required (so, if you have 1.1 and 1.2 installed, > it will pick 1.2). These semantics match those of the 'versions' egg, > I think. On second thought, the syntax above is needlessly complex. (require-library foo bar-1.2 qux-1) is much more straightforward and maps _directly_ to the code in the 'versions' egg, too. It also reserves the "structured library names" like (bar ..) for future enhancements. 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 pgpwu09d0HIon.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Profiling large programs
Thu, 10 Jul 2008 12:39:33 +0200, bunny351 wrote: > See trunk head. You can enable profiling for particular procedures > like this; > > (declare (profile ...)) Works perfectly for me. Thanks for the fast implementation of this useful feature, Felix! pgpb5l0uvGrad.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: Chicken-setup redesign (was: Re: [Chicken-users] Re: getopt, getopt_long?)
On Thu, Jul 10, 2008 at 2:41 PM, Peter Bex <[EMAIL PROTECTED]> wrote: > > To keep things simple, only one version of any egg can be loaded in one > program at a time. > This not only simplifies but is absolutely crucial. But there are many things that should be supported in a redesign: we must try to simplify creating customized or personal repositories, to access them locally (via file-system operations), to have the complete metadata on the host machine and to keep cross-compilation in mind. I would happily assist in the design, if that is acceptable (but I can also keep my mouth shut, no problem). The most important part still is to keep old .setup scripts working, or at least provide backwards-compatibility. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Chicken-setup redesign (was: Re: [Chicken-users] Re: getopt, getopt_long?)
On Thu, Jul 10, 2008 at 09:25:21AM +0200, felix winkelmann wrote: > Allow me a slight rant... > > chicken-setup has served us well, but now has mutated into a large > intricate mess. There has been a rewrite a while ago, but the messiness > is still there, partly because a tool like chicken-setup has to do so > many different things (file-system operations, extension handling, > HTTP download, build invocation, cross-compilation, etc.). I think the > only solution is to > completely dump it and start from scratch. Now would be the time to consider allowing multiple versions of the same library installed at the same time. If we are to make Chicken attractive in business settings, there needs to be a way to keep old stuff working while being able to make use of the latest & greatest when starting new projects. Businesses don't have the time or money to keep upgrading their old code whenever they install new, backwards-incompatible libraries. Of course, this would also require the possibility of loading a particular version of a library. I propose this syntax: (require-library foo (bar 1.2) (qux 1)) This requires the latest installed version of foo (whatever that is), and version 1.2 of bar. From qux the latest installed minor version with major version 1 is required (so, if you have 1.1 and 1.2 installed, it will pick 1.2). These semantics match those of the 'versions' egg, I think. To keep things simple, only one version of any egg can be loaded in one program at a time. 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 pgpVksAfwUlE3.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Profiling large programs
Wed, 9 Jul 2008 13:45:30 -0700 (PDT), elf wrote: > are you inlining anything in the scheme source? Only some functions. I have eliminated these cases (and used -inline-limit 0), but no change. Now I will try Felix' solution ... pgpcRyugnbmPV.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Profiling large programs
On Thu, Jul 10, 2008 at 9:13 AM, <[EMAIL PROTECTED]> wrote: > >> What would perhaps be easier, is to >> allow selective profiling (say by declaring a number of procedures >> that should be profiled). Would this be acceptable for you? > > Yes, that would be an interesting option! > See trunk head. You can enable profiling for particular procedures like this; (declare (profile ...)) cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] strange bug - help needed
forget about it - todays svn version does the job again Am Donnerstag, den 10.07.2008, 11:51 +0200 schrieb Jörg F. Wittenberger: > Am Donnerstag, den 10.07.2008, 12:56 +0900 schrieb Ivan Raikov: > > What is the content of util-chicken.scm? > > helper functions > > attached > > > > > > > Jörg "F. Wittenberger" <[EMAIL PROTECTED]> writes: > > > > > Until I updated to svn trunk today, my program did work fine (as far as > > > I ported it already). > > > > > > Now I see > > > > > > Error: call of non-procedure: # > > > > > > > > > The stracktrace is weird: > > > > > > Call history: > > > > > > util-chicken.scm: 543 create-pipe > > > util-chicken.scm: 544 process-fork > > > util-chicken.scm: 547 sudo! > > > util-chicken.scm: 549 duplicate-fileno > > > util-chicken.scm: 550 duplicate-fileno > > > util-chicken.scm: 551 close-all-ports-except > > > util-chicken.scm: 552 thunk > > > util-chicken.scm: 561 process-execute <-- > > > > > > ...that is if I don't print the value of "process-execute" - if I do, > > > it runs different:� > ___ > 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
Re: [Chicken-users] Proposed addition to tcp unit
Am Mittwoch, den 09.07.2008, 23:14 +0200 schrieb Hans Bulfone: > hi, > > On Wed, Jul 09, 2008 at 02:22:45PM +0200, Jörg F. Wittenberger wrote: > > Hi all, > > > > I wanted to control tcp connections from chicken, but handle the actual > > traffic by an external program. > > > > This appears not quite possible with the tcp unit as it stands. > > tcp-accept starts reading from the accepted connection while my > > connection handler starves. (Or at worst they will share the traffic in > > an unpredictable way.) > > > > To cope with the situation I added "tcp-get-next-client" (which is > > incidentally compatible with rscheme's "get-next-client", since that's > > the code I'm porting). > > > > Is this a general useful addition? I'd appreciate if it would it make > > it into chicken. Will it? > > i cannot decide this, but i have a question: > > your code looks just like tcp-accept (from chicken 3.1.0) except that > you return (values fd (##net#getpeername fd)) and tcp-accept returns > (##net#io-ports fd). Yes, it's just this slight modification. > i don't understand why wrapping the fd in scheme ports should read > anything from the fd if the ports are not used in any way besides > getting the fd out (which doesn't seem to be possible right now - > perhaps also a useful addition :) This is actually possible using port->fileno. I tried this first and got a valid fd; the writing side (chicken -> connection handler) did work well. But reading from connection handler was a mess. > otoh... ##net#io-ports makes the fd non-blocking which it should > and closes them at > some point so you are probably right, a lower-level function should be > available that just returns the plain fd. (and tcp-accept should then > just be (##net#io-ports (tcp-get-next-client-or-something tcpl)) > > i'd prefer tcp-accept* or tcp-accept/fd over tcp-get-next-client. Since this is an single, isolated code spot in my 100kLOC to be ported, I don't mind any name. function first: I want it to fly /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: getopt, getopt_long?
> > I agree about the apt-like functionality, and even proposed the > design of a domain-specific language for such purposes but Felix > thinks it makes things too complicated. Allow me a slight rant... chicken-setup has served us well, but now has mutated into a large intricate mess. There has been a rewrite a while ago, but the messiness is still there, partly because a tool like chicken-setup has to do so many different things (file-system operations, extension handling, HTTP download, build invocation, cross-compilation, etc.). I think the only solution is to completely dump it and start from scratch. If we consider what we essentially need (executing .setup scripts in a directory with the egg sources), a backwards compatible API for executing the build scripts it should be possible to reorganize the installation and upgrading of eggs on a user's system in a simpler, better maintainable and more transparent way. I have actually tried to isolate the pure .setup API (hygienic branch, module setup-api.scm), but haven't got the time or energy to start with such a project (insert the usual *HINT* here - if someone would be willing to go for it, he/she could rely on my eternal gratefulness). I think chicken-setup should NOT duplicate functionality that modern packaging tools provide. Dpkg and portage will always do a better job at that, and it would be more worthwhile to push for adoption of eggs into these packaging systems (which, IIRC, Ivan already does with debianizing several eggs). But a simple, portable, library-only way of fetching a tarball via HTTP, extract, build and install it, upgrade it if necessary and listing what's installed would make all the extensions available to everybody (and that would be enough, IMHO). A bare minimum to have access to all those libraries and keep them up to date. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Profiling large programs
Hi Felix. Thu, 10 Jul 2008 09:10:09 +0200, bunny351 wrote: > Enabling profiling adds considerable decorations to the code (so it's > mostly a pure source-code-level operation). By doing more of the > decoration on the C-level (and with the necessary changes to the > backend), this could be reduced, but there is no quick solution I guessed so too. > What would perhaps be easier, is to > allow selective profiling (say by declaring a number of procedures > that should be profiled). Would this be acceptable for you? Yes, that would be an interesting option! Ciao Sven pgpY6aZ2ueJZ2.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Profiling large programs
On Wed, Jul 9, 2008 at 1:55 PM, <[EMAIL PROTECTED]> wrote: > Hi all. > > Compile times of chicken increase considerably when adding -profile. > For example, > 17 hours on a recent 2.4GHz processor instead of just some minutes > without -profile. > Furthermore, the resulting C file is 1.3GB so that it cannot be > compiled by gcc. Here is the start of the resulting C file: > > /* Generated from nallch.scm by the CHICKEN compiler > http://www.call-with-current-continuation.org > 2008-07-08 18:46 > Version 3.3.1 - linux-unix-gnu-x86 [ manyargs dload ] > SVN rev. 10820 compiled 2008-05-14 on ki220 (Linux) > command line: nallch.scm -debug-level 0 -optimize-level 1 -profile > -output-file nallch3.c > used units: library eval data_structures ports extras srfi_69 profiler > posix srfi_1 > */ > ... > > Does anybody have any hints how to profile a large program? > (Separate compilation is not an option for me, currently.) > Enabling profiling adds considerable decorations to the code (so it's mostly a pure source-code-level operation). By doing more of the decoration on the C-level (and with the necessary changes to the backend), this could be reduced, but there is no quick solution I can offer, other than separate compilation (which, as you already said, isn't possible for you). What would perhaps be easier, is to allow selective profiling (say by declaring a number of procedures that should be profiled). Would this be acceptable for you? cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
