Re: [Chicken-hackers] [Chicken-users] Some questions about CHICKEN 5 eggs and modules
On Wed, 29 Aug 2018 17:20:09 -0400 John Cowan wrote: > On Wed, Aug 29, 2018 at 4:21 PM wrote: > > > > I don't see the motivation for installing files outside of the chicken > > installation > > tree, so it is not clear to me what you want to achieve with this. > > > > From what I understand (which may be wrong) it's so that chicken-install > can put a > file in a place expected by some external library. > [...] Hello, that is precisely the use case I have in mind, yes. Also, on my machine I consider the entire /opt/chicken prefix to be my "chicken installation tree", and I don't want to put anything outside of that, but I do want to put things inside in any location that appears right, not just one of three fixed paths ;-) Ciao, Thomas -- There are only two things wrong with C++: The initial concept and the implementation. -- Bertrand Meyer ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [Chicken-users] Some questions about CHICKEN 5 eggs and modules
On Wed, 29 Aug 2018 14:17:08 +0200 felix.winkelm...@bevuta.com wrote: > > [...] > > I can't say that I like this design decision, but I guess I'll have to > > live with it. If this is unsupported, it also feels strange that > > the .egg format allows specification of multiple import libraries per > > extension at all – the provider side of the picture, when you write a > > library with multiple modules, is supported, but the consumer side, > > when you try to use it, is suddenly not supported any longer. > > I'm not sure what you mean, some example would be helpful here. > [...] Hello Felix, hmm, I was under the impression that we could now declare multiple (modules ...) in an (extension ...) but there was no way to access them because (import ...) would always try to load both the import library and the extension of the same name. However, I just realized that my old default approach of doing (require-library ...) first and (import ...) later still seems to work fine. Only when commpiling such code, CHICKEN will always complain that the extensions with the same names as the modules do not exist, but that's a minor nuisance. So never mind that stupid question ;-) Ciao, Thomas -- There are only two things wrong with C++: The initial concept and the implementation. -- Bertrand Meyer ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [Chicken-users] Some questions about CHICKEN 5 eggs and modules
On Wed, 29 Aug 2018 14:09:01 +0200 felix.winkelm...@bevuta.com wrote: > > [...] > > multiple sets of files may already be possible with multiple component > > forms in the .egg, but installation into any nested subdirectories relative > > to the CHICKEN installation prefix is currently not possible. > > > > For example, some include files provided with the protocol buffers egg > > would technically have to be stored in certain subdirectories of the C > > include path (/extend/protobuf/...) for the protocol buffer > > compiler to pick them up correctly. Currently I have to move those files > > around manually after installation. > > Can you supply me with a sample .egg file that specifies > the case you'd like to have supported? > [...] Hello Felix, you could take a look at protobuf.egg in the CHICKEN 5 branch[1]. There you will find a clause that reads: (c-include extend/protobuf (files "extend/protobuf/bigint.proto" "extend/protobuf/chicken.proto")) What I would like is to install these files as /include/extend/protobuf/bigint.proto /include/extend/protobuf/chicken.proto what actually happens is that these files are installed as /include/chicken/bigint.proto /include/chicken/chicken.proto but the .egg-info file lists /include/chicken/extend/protobuf/bigint.proto /include/chicken/extend/protobuf/chicken.proto The inconsistency between the installation script and the .egg-info file is probably a bug. Additionally I propose that the (destination ...) form should be made relative to the default target directory and create all specified subdirectories as necessary, then I could just add a (destination "../extend/protobuf") to the c-include form above and be happy. At least this would make a lot more sense than the current behaviour where a relative path in the destination form is relative to the source directory where the egg is built, and the correct absolute path for the destination can never be determined correctly at the time the .egg file is written. Ciao, Thomas -- [1]: http://chust.org/repos/chicken-protobuf/doc/chicken-5/protobuf.egg -- I think that in the nuclear world the true enemy can't be destroyed. [...] In my humble opinion, in the nuclear world the true enemy is war itself. -- Cmdr. Hunter from the movie "Crimson Tide" ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [Chicken-users] Some questions about CHICKEN 5 eggs and modules
On Wed, 29 Aug 2018 10:57:54 +0200 felix.winkelm...@bevuta.com wrote: > > As far as I understand the question (probably not really), a simple way to > > do this is to (foreign-declare "#include \"foo.c\"") and add foo.h to the > > source-dependencies of the file (see for example the simple-sha1 and > > simple-md5 eggs, they do this). No need for any special handling. > > > > Of course it means your C files get a lot larger, and you don't benefit > > from reduced compilation times from separate compilation. > > That's right, this will work in many cases. On the other hand, foo.c > will be compiled in the environment that chicken.h defines, including > all macro and type definitions, which may pollute what foo.c expects > to be seen. "Reparing" the environment may range from difficult to > impossible should foo.c have name clashes with anything defined > in chicken.h. Moreover, foo.c may need special compilation flags > that are not compatible with CHICKEN-generated source code. > [...] Hello, I would argue that mashing together C compilation units using brute-force #include is almost never the right thing to do and will rarely work correctly, for the reasons Felix pointed out, unless the code has specifically been written to function in the environment provided by the other header files. C is designed to use a number of separate files to manage the global state of preprocessor and compiler! Ciao, Thomas -- Intelligence may only be the second oldest profession in the world, but it is more immoral and there are more amateurs practicing it than the oldest one. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [Chicken-users] Some questions about CHICKEN 5 eggs and modules
Hello,
multiple sets of files may already be possible with multiple component forms in
the .egg, but installation into any nested subdirectories relative to the
CHICKEN installation prefix is currently not possible.
For example, some include files provided with the protocol buffers egg would
technically have to be stored in certain subdirectories of the C include path
(/extend/protobuf/...) for the protocol buffer compiler to pick them
up correctly. Currently I have to move those files around manually after
installation.
Ciao,
Thomas
On Tue, 28 Aug 2018 14:24:47 -0700 Ivan Raikov wrote:
> Yes, exactly, the issue is installing multiple sets of files in
> different subdirectories of PREFIX/{include,share}. It would be very
> useful for "c-include" as well as "data" components.
> Thanks,
>
> -Ivan
> On Tue, Aug 28, 2018 at 1:07 PM wrote:
> >
> > > I have a couple of eggs that generate and compile code similar to the
> > > way chicken-crunch works. These eggs would install header or source
> > > files that are required for the compilation process. Some of these
> > > source files belong to distinct functional modules that are organized
> > > in subdirectories. In CHICKEN 4, it was possible to install these
> > > files to corresponding subdirectories of CHICKEN_PREFIX/share/chicken,
> > > thus preserving the logical structure. In CHICKEN 5, this is currently
> > > not possible, but I think it would be a very convenient feature. We
> > > can of course define our own conventions and install the additional
> > > files into subdirectories of $HOME, but it makes more sense to me to
> > > keep them in the CHICKEN directory hierarchy. I hope this makes sense.
> >
> > So the basic problem is to install multiple sets of files, in separate
> > steps? I think for "scheme-include" components this should be possible,
> > but (as far as I can see) this is not currently possible for "c-include"
> > components (but could be added).
> >
> >
> > felix
> >
>
> ___
> Chicken-users mailing list
> chicken-us...@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
--
Life is not a battle to win but a melody to sing.
-- Amit Ray
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [Chicken-users] Some questions about CHICKEN 5 eggs and modules
On Tue, 28 Aug 2018 20:40:33 +0200 felix.winkelm...@bevuta.com wrote: > [...] > I'll try to address some of your questions. > [...] Hello, thanks for taking the time to reply :-) > [...] > > - Some eggs install one extension library containing several modules. The > > new > > CHICKEN module system always tries to load a library named the same as the > > module upon import. Is it no longer possible to separate library loading > > and > > module import? How can one consume those "compound" libraries now? > > To simplify the confusion related to "require-extension", "use", etc. > "import" does now both loading and import in one step. "Compound" libraries > [...] must be done manually and is not directly supported by the new > system. > [...] > The underlying machinery is still the same, but in the interest of making > things simpler for the user, the high-level view that can be specified in > egg files provides fewer options. > [...] I can't say that I like this design decision, but I guess I'll have to live with it. If this is unsupported, it also feels strange that the .egg format allows specification of multiple import libraries per extension at all – the provider side of the picture, when you write a library with multiple modules, is supported, but the consumer side, when you try to use it, is suddenly not supported any longer. You also suggest that separating load and import is possible when done "manually", but I couldn't find any information on how one would approach that. Could you elaborate this "manual" approach a little bit? > > [...] > > - If an (extension ...) form in an .egg file lists modules that have a > > composite name, such as (foo bar), the egg installation process then tries > > to > > pass the literal "(foo bar)" as a component of the import library name to > > the > > compiler and it appears in the generated install script. Is this a bug or > > is it > > intentional? It seems inconsistent with the name mangling using "." between > > module name components that is applied elsewhere. > > This is a bug. Compound names should be canonicalized using "." syntax > when they appear in user forms. If you can provide a simple example, we can > try to address this. > [...] $ cat foobar.scm (module (foo bar) (hello) (import scheme) (define (hello) (display "Hello world!") (newline)) ) $ cat foobar.egg ((components (extension foobar (modules (foo bar) $ chicken-install -n building foobar [...] /opt/chicken/bin/csc -setup-mode -s -host -I /home/murphy/foobar -C -I/home/murphy/foobar -O2 -d0 /home/murphy/foobar/(foo bar).import.scm -o /home/murphy/foobar/(foo bar).import.so csc: file `/home/murphy/foobar/(foo bar).import.scm' does not exist Error: shell command terminated with nonzero exit code 16384 "sh /home/murphy/foobar/foobar.build.sh" > > [...] > > - How can I compile multiple source files, for example one scheme file and > > several C files, into an extension library in an .egg file? As far as I can > > see, the only way to do that is a custom build script, but that has > > problems of > > its own. In particular it is nearly impossible to do this right in the case > > of > > static linking, where CHICKEN seems to expect a single object file output > > (yes, > > ELF object files can be merged, but that's a pain in the rear). > > Yes, use a custom build script. I'm working on a way to handle the case of > separate > ..c files that need to be linked. Due to how we support static linking this > is > not trivial. > [...] How about producing .a / .lib files instead of .o files for static linkage – wouldn't that simplify including multiple compilation units? Thanks again for the useful feedback! Ciao, Thomas -- Liebe ist die beste Geisteskrankheit, die man sich wünschen kann. -- Lisa Eckhart ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] chicken-fuse
On 2014-03-18 08:56, Evan Hanson wrote: [...] My thinking was that, because the release callback is used to clean up resources, one would want it to receive the handle value in a form that's already as cleaned up as possible from fuse's point of view (i.e. unevicted). [...] Hello, as far as I can tell and if I understand the CHICKEN manual correctly, object-unevict copies an object into garbage collected memory but does *not* destroy the original evicted copy. So, unless this release callback of yours also frees the evicted copy using the deallocator function matching the allocator function that was passed to the original call to object-evict, this will very likely leak resources *and* perform unnecessary managed allocation operations during cleanup. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Enable -deploy on NetBSD [was: Re: [PATCH] Enable -deploy on OpenBSD]
On 2014-02-01 20:16, Peter Bex wrote: [...] (if (and deployed (or (eq? (software-version) 'freebsd) - (eq? (software-version) 'openbsd))) + (eq? (software-version) 'openbsd) + (eq? (software-version) 'netbsd))) (list -Wl,-z,origin) '()) [...] Hello, the longer that disjunction of conditions gets, the more I feel that something like (if (and deployed (memq (software-version) '(freebsd openbsd netbsd))) ...) would look nicer ;-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] tcp-shutdown
Seth Alves wrote: [...] I have some code that uses the openssl egg. I'm not able to find a way (as a client) to send eof to the server. [...] Hello Seth, you can shutdown the entire SSL connection by closing both the input and output ports connected to the peer. However there is no way to shutdown only the sending or receiving end of a connection like it is possible with BSD sockets. I you close only one of the ports of an SSL connection, the access to that channel from Scheme becomes impossible but nothing really changes on the lower abstraction layers. This is not simply due to my laziness when creating the OpenSSL egg but because I don't know of any safe way to partially shutdown an SSL connection. To my knowledge the OpenSSL API and the SSL protocol itself only support shutting down the entire SSL session and not signalling end of stream on either the input or output channel. [...] I can do something like (tcp-shutdown (ssl-port-tcp-port (cadr ssl-sock)) 1) [...] This is definitely not safe and may lead to data loss. The problem is that any sort of SSL communication, be it receiving or sending data, may trigger features like key renegotiation that would not be possible if one direction of the underlying network transport was disabled. Hence, if you just disable the underlying TCP output channel, your SSL peer will probably see an end of stream on its input channel, but she might not be able to send any more data back to you either! I would suggest implementing the necessary end of stream signalling in a higher level protocol on top of SSL. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] tcp-shutdown
Seth Alves wrote: [...] Search for TCP uses a FIN segment in http://www.linuxjournal.com/node/4822/print and see http://www.openssl.org/docs/ssl/SSL_shutdown.html# So it seems like what I want should be possible. [...] Hello Seth, SSL_shutdown closes the connection in both directions. A call to this function is already triggered by the OpenSSL egg after you have closed both the input and output ports of an SSL connection. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Patch to use better PRNG on BSD's
On Wed, 2012-04-11 at 09:27 +0200, Peter Bex wrote: On Wed, Apr 11, 2012 at 08:49:32AM +0300, Timo Myyrä wrote: Ah, I checked the manual pages of NetBSD-current and it lists arc4random_uniform. [...] Whats the problem of using hosts PRNG. I'd assume every host OS would have decent PRNG. [...] And I'm not so sure the assumption that every OS has a proper PRNG is even valid. [...] Hello, in my opinion this entire discussion is somewhat pointless unless we define what a properties a good PRNG should have for our purposes. For example neither the nonlinear additive feedback generator employed by glibc to implement rand(3) and random(3) nor the RC4 algorithm have acceptable quality for modern cryptographic applications -- they both have output biases and too short periods. On the other hand, for applications that don't require randomness good enough for use in a stream cipher any old PRNG might do the job. It really depends strongly on your application. If we really wanted to include a PRNG in the CHICKEN distribution that should satisfy any definition of good, I would suggest to use a modern stream cipher with high throughput, for example SOSEMANUK [1]. But I'm not sure whether a suite of cryptographic functions is really something that must be included in a language's standard library. Ciao, Thomas -- [1] http://www.ecrypt.eu.org/stream/sosemanukpf.html -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Patch to use better PRNG on BSD's
On Wed, 2012-04-11 at 09:47 -0500, Jim Ursetto wrote: Currently the only reason a better PRNG is needed in core is because of the new hash table randomization stuff that is also in core (as of the upcoming Chicken 4.8). User code can use any one of the random eggs. Cryptographic quality is probably overkill. On Apr 11, 2012, at 6:21 AM, Thomas Chust wrote: If we really wanted to include a PRNG in the CHICKEN distribution that should satisfy any definition of good, I would suggest to use a modern stream cipher with high throughput, for example SOSEMANUK [1]. But I'm not sure whether a suite of cryptographic functions is really something that must be included in a language's standard library. Hello, by the way, SOSEMANUK and other modern stream ciphers reach about one order of magnitude higher data output rate than RC4 on current hardware with 32 or more bits per register. And the speed of the PRNG can easily become an issue, even if it is just used to salt hash tables. The quality of the random data is also an issue if the hash tables are not resalted frequently and the period length of the generator is an issue if they are resalted frequently. Probably it wouldn't hurt at all to pick a really good generator! Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] deprecation of always?, never?, none?
Felix wrote: From: Thomas Chust ch...@web.de [...] for example, in the context of type checking, you may want to represent the fact that a function can never exit through its return continuation by assigning the none return type to it. That's a matter of control flow, not of type. Bottom is not a value, it is undefinedness, in every sense. [...] Hello, well, I think it's both a matter of control flow and types. The border between those things is fuzzy, anyway. I suspect that any statement about the control flow of a program can be expressed as a type if the type system is sufficiently complex. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] functors
2011/3/24 Felix fe...@call-with-current-continuation.org: [...] (module foo (this that (interface: ARITHMETIC) the-other) ...) [...] Hello, just a small remark about the syntax: I find this use of keywords rather unintuitive. I would either expect to be able to write something like this: (module foo (bar baz #:interface ARITHMETIC boing) ...) Or something like this: (module foo (bar baz (interface ARITHMETIC) boing) ...) But a keyword in operator position is unusual and looks rather strange to me. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Cannot access egg svn repo
2011/3/9 Mario Domenech Goulart mario.goul...@gmail.com: [...] Do you get the same behavior if you use a web browser as client (i.e., pointing your web browser to https://code.call-cc.org/svn/chicken-eggs). [...] Hello, Apart from an additional warning that the SSL certificate of the server is considered invalid, my webbrowser also presents an error page with a Forbidden message. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Cannot access egg svn repo
2011/3/7 Kon Lovett konlov...@gmail.com: [...] Has something changed? I now see svn: access to 'https://code.call-cc.org/svn/chicken-eggs' forbidden [...] Hello Kon, not that it is of any help, but I have been seeing the same problem with checkouts or commits on the egg repository for about one week now. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] blob-literal read syntax
2010/10/18 Felix fe...@call-with-current-continuation.org:
[...]
I have added read-syntax for blob-literals and currently use
#{hex...}
[...]
I want to ask if perhaps another syntax might be preferrable. Any
ideas?
[...]
Hello,
it seems useful to me to have such syntax available, but I would find it
even more convenient if the blob could be encoded in base 64 or something
else less space consuming than hexadecimal.
Ciao,
Thomas
--
When C++ is your hammer, every problem looks like your thumb.
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Problem with OpenSSL and file descriptors (sendfile)
2010/7/4 Peter Bex peter@xs4all.nl: On Sun, Jul 04, 2010 at 02:59:14PM +0200, Thomas Chust wrote: [...] * I think ssl-port-tcp-port should be exported from the openssl module. That way it would be possible for client code to call (port-fileno (ssl-port-tcp-port ...)) and use the result in a call to file-select or some other low level status inquiry that requires a file descriptor, which may be useful. Hm, good point. Should it still define ssl-addresses then? It's redundant since user code could do (tcp-addresses (ssl-port-tcp-port p)) manually. Hello, maybe ssl-addresses is important enough to warrant a convenience routine. Maybe an additional ssl-port-fileno procedure would also make sense. If minimalism is a goal, exporting ssl-port-tcp-port would be sufficient, though. [...] * To avoid code duplication I would consider replacing the manual definition of ensure-ssl-port with a use of the check-errors egg, ie. to write (define-check+error-type ssl-port), export check-ssl-port and error-ssl-port as well as ssl-port? and use check-ssl-port instead of ensure-ssl-port. I don't agree here. Using check-errors would make some sense, but would introduce a dependency (openssl didn't require any other eggs up till now) Ok, that's a good point. [...] Also, why should it export the checking procedures? I don't know of any other type or egg that has such checking procedures exported. It's only of marginal use to openssl-using code. For completeness' sake I think *-check and *-error procedures should always be exported if they are defined and a predicate is exported. I was under the impression that most eggs do it that way, but then again not many eggs export new types with predicates anyway. This whole business of using check-errors was just a thought out of an impulse to reuse code where possible. It's not really important and the solution present in the patch is perfectly fine as well! Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Problem with OpenSSL and file descriptors (sendfile)
2010/7/4 Peter Bex peter@xs4all.nl: [...] Anyway, thanks for your feedback. I've added the ssl-port-tcp-port and ssl-port? procedures to the export list, documented them and released a new openssl version as 1.3. I've also added the necessary modifications to Spiffy and now it supports HTTPS out of the box :) [...] Great, thanks for the work :-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Collating prepared statements in sqlite3: bug?
2010/5/15 Peter Danenberg p...@roxygen.org: When I attempt to collate a prepared statement, the arguments to the collation function are the names of the column and not the values thereof. [...] Hello, I just tested this on Linux with CHICKEN 4.5.0, SQLite3 3.6.22 and version 3.5.1 of my sqlite3 egg: I cannot reproduce the problem. [...] SELECT * FROM test ORDER BY ? COLLATE COLLATETHIS LIMIT ? OFFSET ?; [...] What's strange about this statement is that it tries to order the data by the first query parameter, which is a constant for purposes of the SQL statement, and hence recent versions of SQLite3 will never call the collation function at all, since the ordering between a single constant value and itself must never change. So maybe your version of SQLite3 does less optimization and continues to call the collation function on two copies of the first query parameter for every row in the table you query. If you actually intended to make the column by which the query results are ordered variable, the statement you used is not suitable for that purpose, neither is any prepared statement. In that case you actually have to construct and compile a new SQL string for every column by which you want to sort. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] inlining + identity of literals
2010/4/8 felix fe...@call-with-current-continuation.org: [...] Something that I'm not sure how to handle: should literal quoted data keep its identity when the containing code is copied due to inlining? Or should the data be copied as well (the latter is the current behaviour). [...] Hello Felix, I consider it extremely bad style to rely on the mutability of literals, so I wouldn't mind if structurally equal literal constants were folded, whether there is inlining involved or not. However, if I would rely on the mutability of literals, I would still intuitively expect that the same literals keep their identity throughout the code, for example I would expect that every closure generated by (define (make-foo) (let ([p '(0 . 1)]) (lambda () (set-car! p (+ 1 (car p))) (set-cdr! p (* 2 (cdr p))) (* (car p) (cdr p) would always access the same object bound to p. This is precisely the contrast I expect between a quoted literal and a freshly constructed value. In fact this is normally true in CHICKEN, but if inlining copies literals, the property is violated and hence inlining can change the behaviour of the code. In my opinion it would be ideal if compiler optimizations like inlining made some efforts not to change the behaviour of a program. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] serious bug ? in units and set!
2009/9/22 Thomas Bushnell BSG t...@becket.net: What are you talking about? Nothing in test2.scm establishes a binding for foo. [...] Hello, (set! foo 'whiz) at the top level with no previously defined variable called foo *does* establish a binding for foo. Ciao, Thomas -- All these theories, diverse as they are, have two things in common: They explain the observed facts, and they are completely and utterly wrong. -- Terry Pratchett, The Light Fantastic ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] serious bug ? in units and set!
2009/9/22 Thomas Bushnell BSG t...@becket.net: On Tue, 2009-09-22 at 10:30 +0200, Thomas Chust wrote: [...] (set! foo 'whiz) at the top level with no previously defined variable called foo *does* establish a binding for foo. Of course. But test2.scm has no set! at top level: [...] Hello, right, I'm sorry, I misread the original code and thought the set! was outside the function definition :-( Now I find the behaviour somewhat strange as well. For what it's worth, CHICKEN 4.2.0 shows the same behaviour and even stranger things happen when I change the code slightly: $ cat test2.scm (declare (unit test2) (export blah)) (define (blah) (format #t foo: ~s~% foo) (set! foo 'whiz)) $ cat main.scm (declare (uses test2) (export foo)) (define foo #t) (blah) $ csc -o foo test2.scm main.scm foo: whiz $ ./foo $ Why on earth is the content of the procedure definition evaluated at compile time and not at runtime here? Is maybe some compiler magic to blame that tries to optimize expressions into constants even though they have side effects? Ciao, Thomas -- All these theories, diverse as they are, have two things in common: They explain the observed facts, and they are completely and utterly wrong. -- Terry Pratchett, The Light Fantastic ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] serious bug ? in units and set!
2009/9/22 Jim Ursetto zbignie...@gmail.com: I thought I explained why. foo is a hidden binding in test2.scm and there is no initial value in test2.scm so the compiler feels free to simply assign 'whiz to foo starting off, [...] Hello, I do understand that, but first the behaviour feels strange nevertheless and second this still doesn't explain why the (format ...) expression is evaluated at compile time instead of at runtime. The format procedure can, and in my example it does, have side effects, so the call shouldn't simply be replaced with its result even if the variable foo is optimized away and replaced by the only value it ever takes in the compilation unit. I guess to make the compiler happy, one simply shouldn't use the side effecting form of format and employ the printf family of procedures instead ;-) And as far as strange inter compilation unit dependency issues are concerned, I would just use CHICKEN 4 modules to avoid most of the trouble elegantly :-) Ciao, Thomas -- All these theories, diverse as they are, have two things in common: They explain the observed facts, and they are completely and utterly wrong. -- Terry Pratchett, The Light Fantastic ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] bit-set? is inconsistently specified
2009/8/4 Thomas Bushnell BSG t...@becket.net: [...] Is tradition not a sufficient reason for our bit-set? to match common lisp and every other Scheme? (Or is there some other Scheme which uses Chicken's version?) [...] Hello, some research shows that the SRFI-60 argument order of bit-set? can also be found in SLIB and Gambit while the CHICKEN argument order can also be found in R6RS and PLT Scheme (where the procedure is called bitwise-bit-set?). Maybe it would be wise to change bit-set? to the SRFI-60 argument order and add an R6RS compliant bitwise-bit-set? with the existing argument order in the long term. cu, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] bit-set? is inconsistently specified
2009/8/3 Thomas Bushnell BSG t...@becket.net: The chicken scheme library unit defines bit-set? as [procedure] (bit-set? N INDEX) Returns #t if the bit at the position INDEX in the integer N is set, or #f otherwise. The rightmost/least-significant bit is bit 0. Alas, this is inconsistent with srfi-60, which has the parameters in the opposite order [...] Hello, this is unfortunate indeed. However the convention of passing the composite object first and the index after it is much more widespread than what SRFI-60 apparently does. By the principle of least surprise I would always have expected to find the parameters in the order CHICKEN currently uses! cu, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] bit-set? is inconsistently specified
2009/8/4 Thomas Bushnell BSG t...@becket.net: On Tue, 2009-08-04 at 00:34 +0200, Thomas Chust wrote: [...] However the convention of passing the composite object first and the index after it is much more widespread than what SRFI-60 apparently does. By the principle of least surprise I would always have expected to find the parameters in the order CHICKEN currently uses! I agree completely that, if this were being designed from the beginning, the Chicken order is better than the srfi-60 order. Yet, I don't think we get to deal with that. [...] Hello, as far as I can see, CHICKEN neither claims to implement SRFI-60 nor does it implement a large subset of procedures specified there. Also a SRFI is not a binding standard document, but a *request* for implementation. Given all that and the fact that CHICKEN's choice of API convention is probably better than that of SRFI-60 here, I don't see any reason at all, why this behaviour should be changed. However, that is just my personal opinion :-) cu, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] bit-set? is inconsistently specified
2009/8/4 Thomas Bushnell BSG t...@becket.net: I think this argument is fallacious. Chicken Scheme is not consistent in using the data-structure order (alist-ref, alist-update!, rassoc, compress, tail?) and also has cases where it should use the currying order but doesn't. Hello, that's a valid point. Probably tradition is the reason for most of these cases. [...] I would say as well that the question is fundamentally unimportant, and it is far more important to aim for consistency where possible. As it is, I can see no way a piece of Chicken code can reliable use bit-set?, since it is unspecified in what order included units are run; you can't predict whether using srfi-60 or library will take precedence. [...] Does SRFI-60 actually exist as a CHICKEN extension? Anyway, CHICKEN nowadays has a module system, so compilation units can decide separately which bindings with which semantics they want to use. [...] It seems as if you're saying that compatibility has absolutely no weight with you. If that's true, can you explain why? If it's not true, can you describe what weight you think compatibility should play? [...] In my eyes, backwards compatibility is somewhat more important than cross implementation compatibility. This is especially true for Scheme where the huge variety of implementations means you have to be extra careful and expect incompatibilities anyway if you aim for portability across them. That doesn't mean that aiming for greater portability is bad, but complete portability in all areas can probably not be achieved. And I would not expect completely incompatible API changes in the same Scheme implementation unless the major version number is bumped. cu, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] R6RS
2009/8/4 Ivan Raikov ivan.g.rai...@gmail.com: There are many good reasons not to support R6RS. You might want to read them here: http://www.r6rs.org/ratification/results.html [...] Hello, it may also be relevant to point to the ERR5RS standardization effort here: http://scheme-punks.cyber-rush.org/wiki/index.php?title=ERR5RS:Charter In my opinion, the APIs specified there, although minimal, are better than those in R6RS... cu, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers
