[ANN] sdl2 0.4 released
Hello all, Version 0.4 of the sdl2 egg is now available for CHICKEN 4 and 5: https://wiki.call-cc.org/eggref/5/sdl2 This release adds many new features, and type declarations for over 500 procedures to provide improved compile-time checks. It also has a few small changes that break backward compatibility. See the CHANGELOG for full details: https://gitlab.com/chicken-sdl2/chicken-sdl2/blob/master/CHANGELOG.md Thanks to megane and kp for their bug reports, and megane for spearheading an effort to reduce error-checking boilerplate. Enjoy! - John Croisant
Request for feedback on FFI helpers egg (Jiffi)
Hello all, I have been working on a new egg called Jiffi, which provides high-level helpers for writing foreign-function interface (FFI) bindings to C libraries. It is especially helpful for large and complex libraries. I hope it will also lower the barrier for beginners to create high-quality bindings and contribute to the CHICKEN ecosystem. You can read more on the wiki: https://wiki.call-cc.org/eggref/5/jiffi Jiffi is already usable and fully documented. However, before I stabilize the API, I would like some volunteers of various experience levels to try using it to create bindings to a C library (or part of a C library), and provide feedback about any concepts or documentation that are confusing, and any use cases that are difficult to accomplish. My current plan is to accept feedback until mid-August, then try to release a beta with a stable API in early September. You can provide feedback by joining the IRC channel ##jiffi (with two #) on the Libera.Chat network, or by emailing me off-list. Programmers of all experience levels are welcome, and I am happy to provide help writing bindings, and answer your questions. :) - John Croisant
New egg: macaw
Hello everyone, I have published a new egg, macaw. It provides efficient color types, math operations, and color space conversion. It is primarily meant for computer graphics, data visualization, image processing, games, etc. The examples directory has a useful HSL color picker application <https://gitlab.com/jcroisant/macaw/-/blob/master/examples/hsl-picker.scm> in about 300 lines of code. Docs: https://wiki.call-cc.org/eggref/5/macaw Release info for CHICKEN 4 and 5: https://gitlab.com/jcroisant/macaw/raw/master/macaw.release-info Wishing you all good health, - John Croisant
New egg: web-colors
I have published a new egg, web-colors. It provides procedures to parse and write colors in a variety of formats used in HTML/CSS: - Hex colors in #RGB, #RGBA, #RRGGBB, and #RRGGBBAA formats - rgb() and rgba() colors - hsl() and hsla() colors - Named colors, a.k.a. color keywords The egg is mainly targeted at CHICKEN 5, but also works with CHICKEN 4. There can sometimes be differences in the exactness of numbers due to CHICKEN 4 not having a built-in ratio type. Docs: https://wiki.call-cc.org/eggref/5/web-colors Release info for CHICKEN 4 and 5: https://gitlab.com/jcroisant/chicken-web-colors/raw/master/web-colors.release-info Happy new year! - John Croisant
[Chicken-users] [ANN] ck-macros 0.2.0
The ck-macros egg version 0.2.0 has been released. This version adds CHICKEN 5 support, many new features, some R5RS compatibility fixes, and a few breaking changes to the API. https://wiki.call-cc.org/eggref/5/ck-macros ck-macros is based on work by Oleg Kiselyov, with many original contributions by me. It provides a novel kind of macro (or, a novel way of using macros) with two important properties: 1. Aside from wrappers, they are implemented using only standard R5RS features, mostly syntax-rules. So they are trivially portable to pretty much any Scheme, not just CHICKEN. And wrappers are trivially portable to any Scheme that implements er-macro-transformer in the usual way. 2. They can be composed (combined) much like Scheme procedures can. It is even possible to create higher-order macros, analogous to higher-order functions. For example, you can use "c-compose" to compose multiple CK-macros together, then use "c-map1" to map the composed macro over a list. There are many, many examples on the wiki page. The biggest new feature in version 0.2.0 is the "ck-wrapper" procedure, which creates a CK-macro from any Scheme procedure, including lambda forms and "let over lambda" closures. The egg provides wrappers for many standard R5RS procedures, and it's trivial to create your own. If this sounds useful to you, wonderful. Personally, I just enjoy exploring the boundaries of what is possible with this idea -- already much more than I expected! - John Croisant P.S. Please add this to the CHICKEN 5 coop: https://gitlab.com/jcroisant/ck-macros/raw/master/ck-macros.chicken-5.release-info ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Difficulty installing eggs on Chicken 5 on Windows 7 MSYS2
On 2/28/19 6:50 AM, dignified face wrote: > Hello, > > I installed Chicken 5.0.0 on Windows 7 64bit with MSYS2, following the > instructions found here: http://wiki.call-cc.org/msys2 > All works fine, but when I try to install an egg - for instance > "chicken-install matchable" - I get the following error: > > building matchable >C:/msys64/usr/local/bin/csc -host -D compiling-extension -J -s -setup-mode > -I C:\msys64\home\username\.chicken-install\cache\matchable -C > -IC:\msys64\home\username\.chicken-install\cache\matchable -O2 -d1 > matchable.scm -o > C:\msys64\home\username\.chicken-install\cache\matchable\matchable.so > creating subprocess failed > > Error: shell command terminated with nonzero exit code > 1 > "C:\\msys64\\home\\username\\.chicken-install\\cache\\matchable\\matchable.build.bat" > > chicken-do seems to be the problem. I managed to build the egg by copying the > csc invocations from matchable.build.bat then running matchable.install.bat > manually, but this seems like a bad approach. Any help would be greatly > appreciated! > > Thanks in advance, > JJ Unfortunately I don't have a solution, but I have the same problem on Windows 10 MSYS2. Here is a paste with a bunch of information in case it helps someone debug the problem: http://paste.call-cc.org/paste?id=d8878c03d3dbdc1e49f642f3255c893efa18db95 One thing I didn't mention in the paste is that I did a "make check" after compiling and installing CHICKEN, and it seemed to pass. I didn't paste the output of make check because it is extremely long. - John Croisant ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] [ANN] sdl2, sdl2-image, sdl2-ttf eggs ported to CHICKEN 5
sdl2 v0.3.0, sdl2-image v0.2.0, and sdl2-ttf v0.2.0 have been released. The main changes are compatibility with CHICKEN 5 (as well as CHICKEN 4), a more user-friendly installation process, and support for linking to frameworks on macOS. In most cases, the installer should now automatically detect the SDL2 compiler flags necessary for your system. Please let me know if you have any installation problems so I can fix them. Thanks to Christian Kellermann, Kristian Lein-Mathisen, Laughing Man, and Jonas whose bug reports and suggestions made the eggs better. Thanks also to Matt Welland whose email inspired me to finish porting to CHICKEN 5. - John Croisant P.S. Please add these URLs to the CHICKEN 5 coop: https://gitlab.com/chicken-sdl2/chicken-sdl2/raw/master/sdl2.chicken-5.release-info https://gitlab.com/chicken-sdl2/chicken-sdl2-image/raw/master/sdl2-image.chicken-5.release-info https://gitlab.com/chicken-sdl2/chicken-sdl2-ttf/raw/master/sdl2-ttf.chicken-5.release-info ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] [ANN] sdl2 egg 0.2.0
Version 0.2.0 of the sdl2 egg is now available! The sdl2 egg provides bindings to version 2 of the SDL game development library. Highlights of this release include: - Support for 2D accelerated rendering (renderer and texture) - Support for hints (configuration variables) - Support for most SDL 2.0.4 features - Efficient color, point, and rect operations - Performance improvements - Improved integer type checking - Miscellaneous other changes For more details, please see the CHANGELOG: https://gitlab.com/chicken-sdl2/chicken-sdl2/blob/master/CHANGELOG.md Many thanks to Kooda Loutre and Kristian Lein-Mathisen for submitting suggestions which have been implemented in this release. :) - John Croisant ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] [ANN] ck-macros egg
I have created a new egg, ck-macros. If you have ever written a syntax-rules macro and wished that you could expand its arguments ahead of time, this egg may be of interest to you. The egg includes Oleg Kiselyov's "ck" macro, plus about 80 small composable CK-macros written by me, most of them analogous to functions from R5RS, SRFI-1, and SRFI-43. For those not aware (as I wasn't until a week ago), CK-macros are a style of macros which use the CK abstract machine (implemented as the core "ck" macro) to recursively expand the CK-macro's arguments, before the CK-macro itself is expanded. This gives you more control over the macro expansion process, allowing you to easily combine simple reusable macros to form more complex macros. This makes it easy to write portable macros that previously were only feasible using non-portable features like CHICKEN's low level macros. Writing CK-macros is remarkably similar to writing Scheme functions, except they are computed at macro-expansion time, and you have the benefit of syntax-rules pattern matching and destructuring. You can even implement "higher-ordered macros" which take a macro as an argument. For example the "c-map" macro applies a macro to every item in a list, at macro-expansion time. Another nice thing about CK-macros is that all of the macros currently in the egg are implemented using only standard R5RS features, namely syntax-rules and let-syntax. This means they are trivially portable to any R5RS implementation, unlike CHICKEN's low level macros. For more information about CK-macros, including a tutorial about how to write them (it's not hard, but there are a few things you must be careful of), see the egg wiki page: http://wiki.call-cc.org/eggref/4/ck-macros In the future, I plan to add non-portable CK-macros (based on CHICKEN's low level macros) for string manipulation and decimal math. Many thanks to Oleg Kiselyov for creating the "ck" macro, without which this egg would not be possible. Thanks also to "please_help", who mentioned CK-macros on IRC, which led me to learn about them. - John Croisant ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] [ANN] sdl2-ttf 0.1
Version 0.1 of the sdl2-ttf egg is now ready. The sdl2-ttf egg provides bindings to SDL2_ttf, a library for rendering text using TTF, OTF, and FON font files. This egg is designed to be compatible with the new sdl2 egg, which provides bindings to SDL2, the popular game library. * sdl2-ttf docs: http://wiki.call-cc.org/eggref/4/sdl2-ttf * Issue tracker: https://gitlab.com/chicken-sdl2/chicken-sdl2-ttf/issues Here is the release-info file. Please add it to egg-locations. :) https://gitlab.com/chicken-sdl2/chicken-sdl2-ttf/raw/master/sdl2-ttf.release-info Happy holidays, - John Croisant P.S. Don't forget about the Lisp Game Jam coming up January 1! http://itch.io/jam/january-2016-lisp-game-jam ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Bug: define-foreign-type causes confusing messages to be printed
I have observed some strange compiler behavior while developing the sdl2 egg, and now I have finally gotten an idea of what is causing it. If you use define-foreign-type and provide argconvert and retconvert procedures, but never use that foreign type in a function binding as a return type or argument type, the compiler will print out messages such as "Note: global variable `foo#g11' is only locally visible and never used". One or two messages like that are printed for every unused foreign type, depending on whether it is used as a return type, an argument type, or neither. For an egg like sdl2, which has many foreign types, this causes over a dozen messages to be printed when the egg is compiled. This is not a big problem, but it is a bit annoying and confusing. It can cause the developer or users to wonder if something is wrong, and how to fix it. It is especially perplexing because these seem to be gensyms, which are never found in the original source code, so you can't search to find where in your code they might be coming from. Example: Create file foo.scm containing this code: (module foo () (import scheme chicken foreign) (define (unwrap x) x) (define (wrap x) x) (define-foreign-type my-type c-pointer unwrap wrap) ) Compile with: csc -v foo.scm Compilation succeeds, but the following messages are printed: Note: global variable `foo#g11' is only locally visible and never used Note: global variable `foo#g10' is only locally visible and never used I would like it if the compiler did not print these messages. Perhaps the compiler could automatically (declare (unused g10 g11)) or something. Alternatively, the compiler could print a more informative message, such as "foreign type `my-type' is never used", so that it is more obvious what is causing the messages. But personally, I would rather just silence the messages, and that is probably easier to implement anyway. I have reproduced this issue with CHICKEN 4.9.0.1 and 4.10.0. I have not tried other versions yet. I am using Mac OS X 10.10.5. `chicken -version` says: Version 4.10.0 (rev b259631) macosx-unix-clang-x86-64 [ 64bit manyargs dload ptables ] compiled 2015-08-04 on yves.more-magic.net (Linux) Some observations: These messages are only printed if you provide an argconvert or retconvert procedure to define-foreign-type. They are not printed if you pass only the first two arguments, e.g. (define-foreign-type my-type c-pointer) These messages are not printed if you actually use the foreign type as both a return type and an argument type of foreign lambdas. If you use the foreign type only as a return type, or only as an argument type, the compiler will print only one message. Looking at CHICKEN's compiler.scm around line 1055, I see this in the code related to define-foreign-type: (let ([arg (gensym)] [ret (gensym)] ) (##sys#hash-table-set! foreign-type-table name (vector type arg ret)) (mark-variable arg '##compiler#always-bound) (mark-variable ret '##compiler#always-bound) (hide-variable arg) (hide-variable ret) ... This seems like the compiler is already trying to declare the gensyms as unused/hidden/whatever. So, I'm not sure why the messages are still being printed. Maybe those declarations are not sufficient, or maybe the cause is elsewhere. I hope this information helps fix the cause of these confusing messages. :) Thanks! - John Croisant ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] January 2016 Lisp Game Jam
Attention CHICKEN game programmers, There is a Lisp Game Jam coming up on January 1. You have 7 days to create a small game using any Lisp dialect, including CHICKEN Scheme. Think of it as a friendly, low-pressure opportunity to practice your game development skills and create something fun. CHICKEN has many game libraries and bindings, such as Allegro, Chipmunk, OpenAL, OpenGL, and SDL. Or you could create a text console game, or even a web browser game using awful and/or spock! I will be participating, using the jam as an excuse to create another example game for the new sdl2 and sdl2-image eggs. I will also be hanging out in the #lispgames and #chicken IRC channels on freenode as much as I can during the jam, to answer anyone's questions about the sdl2 and sdl2-image eggs, and about game development in general. My IRC nickname is jacius. You can find more info and join the jam at http://itch.io/jam/january-2016-lisp-game-jam . Don't forget to introduce yourself in the community forums. :) Happy new year and happy jamming to all! - John Croisant ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] [ANN] sdl2 and sdl2-image 0.1
Version 0.1 of the sdl2 and sdl2-image eggs are now ready! The sdl2 egg provides bindings to Simple DirectMedia Layer 2 (SDL2), a popular library used in games and other media-rich software. The sdl2-image egg provides bindings to SDL2_image, a library for loading various types of image files to be used with SDL2. I have made an effort to create programmer-friendly, convenient, thorough, and well-documented bindings. They take care of the annoying low-level C stuff for you, so you can focus on making your game. Although the version numbers for these libraries are only 0.1, they are ready to start using now. Some features have not been implemented yet, but it is already possible to create many types of games, even 3D games using OpenGL (when combined with the gl-utils or opengl eggs, for example). Several demos and example programs are available to help you get started. Large backwards-incompatible changes are unlikely, but there may be small tweaks and fixes to the API if problems are discovered. There may be some bugs, but they will be fixed promptly if you report them to the issue tracker. * sdl2 docs: http://wiki.call-cc.org/eggref/4/sdl2 * sdl2-image docs: http://wiki.call-cc.org/eggref/4/sdl2-image * Examples: https://gitlab.com/chicken-sdl2/chicken-sdl2-examples * Issue tracker: https://gitlab.com/chicken-sdl2/chicken-sdl2/issues I also intend to eventually create bindings for other libraries, such as SDL2_ttf (text rendering), SDL2_mixer (sound effects and music), and SDL2_gfx (shape drawing and image transformation). Here are the release-info files for the two new eggs. Please add them to egg-locations. :) https://gitlab.com/chicken-sdl2/chicken-sdl2/raw/master/sdl2.release-info https://gitlab.com/chicken-sdl2/chicken-sdl2-image/raw/master/sdl2-image.release-info Cheers, - John Croisant ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [ANN] sdl2 and sdl2-image 0.1
On 12/19/15 11:11 PM, Evan Hanson wrote: FWIW, the sdl2 egg fails to build with gcc-4.6: In file included from sdl2-internals.c:14:0: lib/sdl2-internals/custom-functions.c: In function ‘chickenSDL2_RotateSurface90’: lib/sdl2-internals/custom-functions.c:212:3: error: ‘for’ loop initial declarations are only allowed in C99 mode lib/sdl2-internals/custom-functions.c:212:3: note: use option -std=c99 or -std=gnu99 to compile your code lib/sdl2-internals/custom-functions.c:213:5: error: ‘for’ loop initial declarations are only allowed in C99 mode lib/sdl2-internals/custom-functions.c: In function ‘chickenSDL2_FlipSurface’: lib/sdl2-internals/custom-functions.c:267:3: error: ‘for’ loop initial declarations are only allowed in C99 mode lib/sdl2-internals/custom-functions.c:268:5: error: ‘for’ loop initial declarations are only allowed in C99 mode Building with gcc-5 instead worked fine. The sdl2-image project didn't have this problem. Thanks for this report. I have fixed the issue by changing the code to declare the variables before the for loop. I will make a 0.1.1 bugfix release in a few days, after more people have had some time to maybe report some more bugs. :) For future reference, here is the issue I filed on your behalf: https://gitlab.com/chicken-sdl2/chicken-sdl2/issues/29 Thanks again! - John Croisant ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New SDL2 eggs; help wanted
On 11/4/15 3:41 PM, Kooda wrote: On Wed, Nov 04, 2015 at 01:35:13PM -0800, Dan Leslie wrote: As a potential user and implementor of similar eggs (Allegro, SOIL, .. nanovg), I would provide fairly lean bindings first, then do any simplification or hand-holding as an additional module. It will save you time in the near term and provide flexibility to the users. -Dan It seems to already be the case. There is a sdl-internals module used by the public sdl2 module. Yes, the sdl2 egg is implemented as two modules, sdl2 and sdl2-internals. The sdl2-internals module is not considered part of the public API, and does not have the same stability guarantees. But, some parts of it are safe to use, which I have today written a guide to document: https://gitlab.com/chicken-sdl2/chicken-sdl2/blob/master/docs/using-sdl2-internals.md So, if anyone really needs to drop down to a lower level, the low-level bindings *do* exist. But I hope most people will not need (or want) to do that. If there are low-level operations that people need to perform, please submit a feature request so I can consider providing support for it to the sdl2 module. That said, the purpose of this egg is only to provide convenient access to SDL2's features. It is not a high-level game framework or engine. (But it would be a good foundation for someone to build a high-level game framework or engine on top of.) - John Croisant ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] New SDL2 eggs; help wanted
Hello everyone, I am working on new eggs that provide bindings to version 2 of Simple DirectMedia Layer (SDL), the popular game development library, and related libraries. The eggs will soon be ready for an alpha release, with partial functionality. I am looking for people to help with testing, documentation, and creating demos and example games. The APIs are not yet set in stone, so please take a look, try the eggs out, and send me your feedback. I am already planning to make procedures signal exceptions when an error occurs, instead of returning error codes like the C library does. - sdl2: http://wiki.call-cc.org/eggref/4/sdl2 - sdl2-image: http://wiki.call-cc.org/eggref/4/sdl2-image - Examples: https://gitlab.com/chicken-sdl2/chicken-sdl2-examples I am also planning to eventually make eggs for SDL_mixer 2, SDL_ttf 2, and (parts of) SDL_gfx 2. CHICKEN already has eggs for version 1 of SDL and some related libraries. These new eggs are for version 2 of SDL, which has many new features and improvements. These eggs are new codebases (not updates of the earlier eggs), and I am working to create very polished, thorough, and maintainable eggs. Currently the project needs people to help with: - Manual testing (installing, running examples) on different platforms - Writing unit tests and semi-automated test programs - Writing API reference docs, guides, and tutorials - Creating detailed installation instructions for different platforms - Creating feature demos and example games/programs In the longer term, I want to provide good instructions, tooling, and a project template for building and distributing self-contained CHICKEN games for various operating systems. If you have experience making self-contained CHICKEN apps, especially apps using C libraries, and you would be willing to answer some questions or help out, please contact me. If you are interested in helping in any way, please send me an email. Thanks, - John Croisant ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] which RxRS?
Giorgio, This is not the proper venue for rehashing or ranting about the Scheme standardization process. And, it's very inappropriate to vilify and insult other community members. Your original question was answered by Christian Kellermann. Let's leave it at that, and not start another flame war. - John Croisant On 12/10/13 7:08 PM, Giorgio Flaverli wrote: @John Cowan; An Olin Shivers-style rant (the Jack'n'Zac one that opens the SCSH manual) would be extremely tempting given your lack of ability to comprehend the immense harm that your position brought to the unique value proposition of Scheme. I've noticed there is little hope arguing with people like you. Everytime you introduce a new standard, especially one that is backwards-incompatible, you split the codebase. Some people will write R6RS code that is incompatible with R5RS and R7RS implementations. Some people will write R7RS-large code that is incompatible with R6RS (and R7RS-small). Now we have R6RS which is even FORWARD-incompatible, and the 2 R7RS's which are SIDEWAYS incompatible, and you can't see a problem with this. This is bad for people who target multiple implementations. Nobody wants to write 5 versions of code because Chicken, Guile, Racket etc each decided to target a different standard, or haven't upgraded to the latest madness from the ADHD-impaired standardizers *just yet*. It's also bad for people who target a single implementation, because your code that runs today might no longer run a few years later as the implementation moves on, or the R(x-1)RS support in the implementation starts receiving less support etc. 2007 was a particularly bad year to split a community and waste efforts, as Scheme still had a good chance to be adopted for modern stuff (web frameworks, map reduce maybe). Another problem: anything other than a small standard makes it hard to write Scheme interpreters for everything. This was the amazing thing about Scheme. Want to drive your embedded system? Go ahead and embed a tiny scheme interpreter. Want to drive JVM code? Use KAWA or Sisc. Want to drive an Ocaml program? Embed OCS. R7RS-small might be good, but when lots people write R7RS-large code, and some write R6RS, a lot of code will be useless to minimalistic implementations. Finally, it's sad that this whole disaster was fostered upon the community un-necessarily. There was absolutely nothing wrong with extending Scheme via the SRFI process, particularly on the library side. In fact it was an amazingly effective way to assemble a small, interested community and develop a facility in an organized and controlled manner (as opposed to having a large electorate of non-experts trample over everything and argue over bike-shed issues over tens of messages, like a bunch of 'tards). The fact that most SRFI's had reference implementations **in scheme** made it extremely easy to add such facilities to a minimalistic interpreter. In the meanwhile a big implementation could write a C implementation of the SRFI. Programs would simply use (require-extension (srfi NN)) and not have to care about such details. Some SRFI's require interpreter support, of course, and users can pressure implementors to add SRFI NN support if it's important to them. So I don't think my language was excessively harsh. You really have no idea what you're talking about advocating multiple incompatible standards and huge incomprehensible standards instead of the concise gems that R5RS and R4RS were. With people like you on the loose a language can be destroyed (and probably was destroyed, as it's hard to compete with Python nowadays for any language; back in 2007 there was still a a chance to focus on software, not on misguided standards). -Original Message- From: John Cowan co...@mercury.ccil.org To: Giorgio Flaverli flave...@aol.com Cc: chicken-users chicken-users@nongnu.org Sent: Tue, Dec 10, 2013 7:43 pm Subject: Re: [Chicken-users] which RxRS? Giorgio Flaverli scripsit: I've gradually lost touch with Scheme after the R6RS debacle. It was a sad day to witness the victory of the pushers of complexity, helped along by a large number of well-meaning morons who should never have been allowed in the electorate given that they never even came close to implementing a meta-circular. I wonder how much more successful Scheme could have been without this disaster and without the harmful actions of those individuals who caused it. This is excessively harsh and downright insulting language. R7RS-small is, I believe, a substantial improvement over R5RS, but it could not have been achieved so easily and completely without R6RS first paving the way. R6RS provided a model of what standards can aim for as well as what they should not aim for. For example, the R7RS-small committee adopted the R6RS exception-handling system unchanged, but rejected the R6RS condition system because it was backward incompatible with all
Re: [Chicken-users] reader macros
On 5/13/13 4:55 PM, John Cowan wrote: Răzvan Rotaru scripsit: I have not found information about this topic, so I have to ask here: does chicken provide reader macros? See http://wiki.call-cc.org/man/4/Unit%20library#reader-extensions. To add to that: be aware that you have to load reader extensions in a special way if you want to use them when compiling your code. To do it, use the -X flag when running the chicken command, for example: chicken -X my-reader-extension-module my-source-file.scm That loads the reader extension _before_ it starts compiling your code, which allows the reader extension to be available at compile time. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
On 2/21/13 9:55 AM, Nicholas Van Horn wrote: On Wed, Feb 20, 2013 at 1:24 PM, Dan Leslie d...@ironoxide.ca mailto:d...@ironoxide.ca wrote: I'm not certain what you intended by 'official', but if you meant that you'd like to see it packaged with Chicken then perhaps you should consider switching the license to Chicken's license. Mind you, GPL3 eggs are happily accepted, but note that many folks won't touch them for various reasons. However, if this is a port of an elisp library then likely re-licensing is not an option. I would love to package this under the BSD license, but as far as my limited knowledge is concerned, it seems that I must keep the GPL3 license of the original elisp package. If someone is aware of an alternative solution, please speak up and I'll change things accordingly. I am not a lawyer, what follows is not legal advice, etc. ... It's possible to change the license by clean room reverse engineering the library, since the new code would (from a legal standpoint) not be a copy or derivative of the original code. To do that: someone who has not seen any of the contaminated source code (i.e. the original library or your port) reimplements the library from scratch based only on a general description of the original library's API and behavior, (e.g. your README file). Then, they can attach any license they wish to the new code. This approach is typically used to reverse engineer proprietary software, for example to create an open source clone. But there's no reason it couldn't be used to create a clone of another open source library with a different license. The downside is that it might be considered rude or disrespectful by some people in the open source community, especially if you use the exact same library name and function names as the original. On the other hand, this library is so simple and obvious that I think it would be very silly for anyone to be offended by it being cloned. - John ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] [ANN] New egg: protolk
Greetings, Chickeneers. I have just released a new egg, protolk: Protolk provides flexible object oriented programming in Scheme, combining encapsulation and message passing a la Smalltalk and Ruby, with prototypal inheritance a la Self and JavaScript. You might be wondering how how Protolk differs from existing prototype-based object systems available for Chicken, such as JSO, Protobj, and Prometheus. JSO and Protobj are simpler, with no encapsulation or message passing, as far as I can tell. Prometheus is the most similar to Protolk, but there are some stylistic differences, especially related to inheritance and slots (Prometheus is inspired more by Self, and Protolk is inspired more by Ruby). I have created a page for protolk on the Chicken wiki (https://wiki.call-cc.org/eggref/4/protolk), but at the moment most of the documentation is on the project wiki: https://github.com/jacius/protolk/wiki . Once the API is more set in stone, I will add the API docs to the Chicken wiki so that they are searchable in Chickadee. This is my first significant project written in Chicken (or even Scheme), so I would like to hear constructive feedback about code style, organization, etc. Regards, - John Croisant (jacius) ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug with #!optional in Chicken 4.8.0
On 10/17/12 4:22 AM, Felix wrote: So I wonder: is there any problem with simply adding support for a second arg to the parameter-functions, without removing the arg check for all procedures that use #!optional? Even in Chicken 4.7, parameter-functions silently accept extra arguments, so there would be no user-visible change in the way parameter-functions are called. That is correct. The first problem here is that there exist procedures that behave like parameters, but aren't (current-input-port, for example - this has historical reasons). The second problem is that there is no reason parameterize shouldn't work for any procedure with a single optional argument. [...] No, you are basically right. Doing the check would be better (not *that* much better, but it would be The Right Thing to do), including a proper implementation of parameters (perhaps with 2 different entry points, or some handler hidden inside the parameter closure, or whatever). I just can't do it right now. Now I understand what you mean about parameter-like procedures. Supporting them does indeed make the situation more challenging. But, if we could somehow distinguish between real parameters and parameter-like procedures, we could be sure to only send the bypass guard/conversion procedure flag when restoring the old value to real parameters. If there is already some way to distinguish between them, that would be perfect. Otherwise, maybe we could use lambda decorators to mark real parameters when they are created in make-parameter? I am not really familiar with what lambda decorators can do, so maybe what I am saying is not possible (or is just a stupid idea). Of course, instead of writing more and more hacks, there is the option of creating a proper implementation of parameters, as you say. What would be different in the proper implementation, versus the current implementation? Is this something that an experienced programmer who has never before hacked Chicken internals could help with? From your earlier comments, it sounds like creating a new implementation would have a high risk of accidentally breaking stuff, especially because of threading. But that risk could be significantly reduced if we create a good test suite before the change. Even if I don't know have enough experience with Chicken internals to implement proper parameters, I could certainly help write tests. Basically, I really want to see the proper behavior of #!optional restored, and I am willing to help in any way I can. Just let me know how I could be most useful. - John P.S. I don't know why I care so much about this issue. It's not that I depend on #!optional so much. I guess I am just shocked that such a basic language feature could be altered without any public discussion (that I can find) or even a mention in NEWS. I like having order and stability in the universe. ;-) ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug with #!optional in Chicken 4.8.0
On 10/15/12 10:51 AM, Felix wrote: [...] It can be considered a bug, indeed. The problem is that we have to pass an additional argument to parameter-functions to mark the situation when a parameter gets restored. parameterize expands into something like (let ((param1 ...) ...) (let ((old-value1 #f) ...) (dynamic-wind (lambda () set old-valueN to value of paramN) (lambda () body) (lambda () restore value of paramN The restoration can not simply by (paramN oldval), since we must avoid calling the guard procedure (if it exists). Being too lazy / too afraid to change the implementation of parameter procedures (which is relatively complicated, including threading issues, as parameters are thread-local), and because I saw the opportunity to cut a tiny bit of runtime by simply omitting the check for surplus arguments (as is done in various old-school Lisp dialects, in C (or undeclared procedures, or procedures with ...), in Lua, and in a number of other scripting languages), I decided to drop the check completely. The parameterize- issue is now handled by simply passing an extra flag argument that indicates restoration. Parameter-like procedures that take a single optional argument will be handled transparently - they simply ignore the second flag argument, which is fine, as they don't have a guard procedure. I hope this explanation is not too confusing. If it is, I'll try to give more examples. Note that R5RS only requires rest-arguments, which, by definition, can be of arbitrary length. Chicken's #!optional just builds on top of R5RS' rest-parameters, BTW. I had a lot to say about rest args and optional args being two different things from a user's perspective, and each one has different uses and expected behavior. But, I think I have already talked too much about why the old behavior should be restored. So instead, I will just suggest a possible technical solution. :-) Here is how I understand the situation: in order to avoid unnecessary computation, we want to avoid invoking the guard procedure when the old parameter value is restored at the end of parameterize. So, we need parameter-functions to accept a second arg, which is a flag to tell it to bypass the guard procedure. So I wonder: is there any problem with simply adding support for a second arg to the parameter-functions, without removing the arg check for all procedures that use #!optional? Even in Chicken 4.7, parameter-functions silently accept extra arguments, so there would be no user-visible change in the way parameter-functions are called. The only bad effect I could see, would be that Chicken users might think the ability to bypass the guard procedure is a real feature of Chicken, instead of a hack to make parameterize more efficient. But, that problem could be avoided by checking that bypass guard argument is a certain unexported symbol (maybe even a gensym) that Chicken users would not (normally) have access to. To put it into pseudocode, a parameter-function might behave something like this: | (lambda args (case (length args) ((0) (get-this-parameter-value)) ((1) (set-this-parameter-value (guard-procedure (car args (else (if (eq? ##bypass-parameter-guard## (cadr args)) (set-this-parameter-value (car args)) (set-this-parameter-value (guard-procedure (car args)))|| | This is still a hack, but at least it is just a small hack which affects only parameterize, and only in the intended way (bypassing the guard procedure when restoring their value). Then, the old behavior of #!optional can be safely restored. Maybe I have misunderstood something, and this solution would not work for some reason. If so, please help me understand. - John ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug with #!optional in Chicken 4.8.0
On 10/14/12 7:20 AM, Felix wrote: From: John Croisant j...@croisant.net Subject: [Chicken-users] Bug with #!optional in Chicken 4.8.0 Date: Sat, 13 Oct 2012 20:34:26 -0400 In Chicken 4.8.0, procedures defined with #!optional no longer signal an exception if invoked with too many arguments. For example: (define (foo x #!optional y) (list x y)) (foo 'x 'y 'too 'many 'args) In Chicken 4.7, this would signal an exception, because the foo procedure expects a maximum of 2 arguments. In Chicken 4.8, the extra arguments are simply ignored. I think this is a bug, because the docs for Extended DSSSL style lambda lists say: If there is no rest-parameter and no keyword-parameters in the parameter-list, then it shall be an error for any extra arguments to be passed to the procedure. That is correct. The check has been removed and conflicts with the documentation. I will update the docs accordingly. The check has been removed to accomodate a terrible hack for handling re-initialization of parameters with parameterize, and for a slight performance win. The hack is so terrible, I hardly dare to talk about it in public. On the other hand, I see no problem in allowing extra parameters to lambdas with rest/optional arguments being silently dropped - it has been done before. cheers, felix The new behavior may not break very much currently existing software (although it did break some of my unit tests), but future software written in Chicken will start to depend on the new behavior, so changing the behavior back in the future *would* break existing software. So, we should address this soon, while the pain of changing back is still minimal. The old behavior was useful and valuable for (at least) two reasons: 1. It provided clear and immediate feedback if the procedure was called incorrectly, making the mistake much easier/cheaper to fix. (Even experienced professional programmers make this kind of mistake sometimes.) 2. It was consistent with the behavior of optional args in many other widely-used programming languages. The new behavior can be useful in some situations, but it was already very easy to implement: just add a rest arg to any procedure that should ignore extra args. On the other hand, it takes a significant amount of code/effort for developers to (correctly) reimplement argument count checking in their own libraries and applications. So, for all those reasons, I think this should be considered a bug and fixed as soon as possible. Perhaps if you describe the parameterize problem (or link to discussion about it elsewhere), someone can think of an alternative solution that will not require changing the behavior of optional args? Regards, - John ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Incorrect hash-table-size for copied hash tables
I have discovered a bug in hash-table-copy and/or hash-table-size. If you copy a non-empty hash table, hash-table-size will report that the copy has 0 entries. But if you use hash-table-ref, hash-table-alist, etc. you will see that the copy actually has all the expected entries. The only thing incorrect is the size reported by hash-table-size. It seems like an internal counter is being initialized to 0 in the copy, when it should be the same value as the original hash table. Adding a new entry to the copy increases the size by 1, setting an existing entry has no effect on the size, and deleting an entry decreases the size by 1. That behavior is normal, but because the counter starts at 0, the size can become negative, which is nonsense. :) I'm seeing this bug in Chicken 4.7.0 and 4.7.3 (from Git) on Linux. I'm having trouble compiling Chicken 4.7.3, so I don't know if this bug still exists in the latest code from Git. Example: #;1 (use srfi-69) ; loading library srfi-69 ... #;2 (define h1 (alist-hash-table '((0 . 1) (2 . 3) (4 . 5 #;3 h1 #hash-table (3) #;4 (hash-table-size h1) 3 #;5 (define h2 (hash-table-copy h1)) #;6 h2 #hash-table (0) #;7 (hash-table-size h2) 0 #;8 (hash-table-alist h2) ((4 . 5) (2 . 3) (0 . 1)) #;9 (hash-table-set! h2 6 7) #;10 (hash-table-alist h2) ((6 . 7) (4 . 5) (2 . 3) (0 . 1)) #;11 (hash-table-size h2) 1 #;12 (hash-table-set! h2 4 8) ; -- replace entry for 4 #;13 (hash-table-size h2) 1 #;14 (hash-table-delete! h2 0) #t #;17 (hash-table-size h2) 0 #;18 (hash-table-delete! h2 2) #t #;19 (hash-table-size h2) -1 ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
