Re: [Chicken-users] environments egg
On 2/14/07, Daishi Kato [EMAIL PROTECTED] wrote: On 2/14/07, Arto Bendiken [EMAIL PROTECTED] wrote: I've just uploaded an initial version to the SVN repository (it's in contexts/trunk/). I'll be adding unit tests and some documentation [2] in the next few days - you may want to hold off till those are in place (though the egg is not that difficult to understand from the source, either, at a couple hundred LOC). I think I understand what is going on. My question would be how much the overhead is. It should at least be slower than the normal eval. Yes, I expect it will be slower. Ah, I see. That is why you want to redesign it just like the sandbox. Thanks for your egg anyway, many things for me to help learning. In case you're interested, there are some namespace-related papers here: http://library.readscheme.org/page11.html http://library.readscheme.org/page5.html -- Arto Bendiken | [EMAIL PROTECTED] | http://bendiken.net/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] gtk2.egg
On 2/13/07, Andre Kuehne [EMAIL PROTECTED] wrote: Tony Sidaway wrote: [...] The main part of the code is a pretty straightforward wrap of libgtk2 and libglade. The only unusual thing is that a bespoke wrap program is used instead of SWIG, and relies on defs files that are published by the (Python) PyGTK project. I have no experience with writing glue-code, just curious. What's the advantage over SWIG? Does this approach make it easier to stay compatible with new gtk versions, since PyGTK is guaranteed to be? SWIG is excellent, but it's an automated tool and has limitations. For instance SWIG is unlikely to be able to reconstruct the object structure of the library components because the code is C and the underlying object definitions are partly a matter of coding convention and partly due to GTK+'s runtime object support system, gobject, of which SWIG understandably knows nothing. I inherited the wrapping code from Tony G, and he seems to have done an excellent job of capturing the object semantics, partly because they are encapsulated in the PyGTK definitions which are used to guide the wrapping process. By the way I'd forgotten that there is actually a very good manual to this egg in the doc directory. I've decided to split off the gobject part of the library, and the glade part, each into its own egg. The Glade code doesn't have any dependencies on the gtk binding, so it's perfectly possible to have a working Glade application in Chicken with only the gobject egg and the glade egg. Glade also has a lot of potential in Scheme because its object model is XML, and Scheme + sxml + Glade would probably make a very good GUI scripting toolkit. Other candidates for splitting off are gdkevent (low level event support) and gdk itself (drawing kit). There is also the possibility of splitting the GTK code into basic. intermediate and advanced modules. I'd have to satisfy myself that basic and intermediate modules would be useful for producing real code, but there is also an impetus here to make the huge wodge of code more manageable, as well as reducing installation time. The gobject code, for instance, takes a few seconds to install on my system, and I would like to produce a basic install for gtk that took a comparable amount of time, so that the programmer evaluating this egg could download and run example code casually before committing himsel to a long egg install to get at the juicy stuff needed to produce advanced Scheme GUI code. Attached is a drop-in-replacement for extract-all-types. Thanks. I've been away from the net for a couple of days and I also wrote a replacement in Chicken. Additionally the script excludes gdk_window_get_type. Otherwise i get this compile error: I think I need to work on the wrapping. The egg should perhaps contain a master file containing information merged from all defs files, with information about how the functions have evolved. Only those definitions pertaining to the GTK version we're building for should be selected during a particular build. In my working copy I've hand-coded some of the NULL-sentinel varargs functions, but wrap.scm should be fixed to take care of this itself. The functions in question are well flagged in the header files (at least for recent versions) although not in the defs files. Besides the error mentioned above, it compiles against my gtk+ 2.10.6. However most sample-apps crash: Yes, it's early days. It's good news that it seems to be close to working on recent releases of GTK, but we have to live with the fact that many installed Gnome systems are built on top of GTK releases that are somewhat behind the cutting edge, and I myself would hesitate to rebuild the foundation of my Gnome system's GUI, lest something break and I end up with no GUI for a while. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Centralized documentation
On Tue, Feb 13, 2007 at 05:00:27PM -0500, Alejandro Forero Cuervo wrote:
* Any improvements to the CSS used by the wiki would be more than
welcome. :-)
I've spent a couple of hours hacking the CSS. The result can be viewed
at http://frohike.homeunix.org/stream-wiki.html
Feel free to snarf the CSS and plug it in the current wiki.
I tried to match the eggdoc default CSS colorscheme. call/cc.org uses
this colorscheme as well.
This CSS was prepared on the basis of the original HTML as it was found
on the wiki. I'd give this a huge overhaul, if possible, though.
It's very unsemantic and suffers from a disease webdevelopers call
divitis, which means there are too many DIVs/SPANs thrown in for no
reason, or as substitutes for UL/OLs. Also, there is a lot of class abuse.
A small example straight from the source:
div id=info-box class=info-box
span class=info-box
a class=info-box href=xsvnwiki-atom/stream-wikiXML/a
/span
/div
1) It's pointless to define both a class and an id on the toplevel DIV.
Just the id should suffice since there's only one info-box on the page, ever.
2) It's pointless to define the same class on all sub-elements of the
info-box. If you're trying to be generic and target all things of class
info-box (bad name since the id of the thing is also an info-box. Classes
should rarely, if ever, shadow ids), you'll get into trouble because you're
actually targeting more than you want to target.
3) If I want to target the inner link, I don't have to have a class to
target it:
/* Target the direct descendent of a span which is a direct descendent of
anything with id info-box and give it the color #99. */
#info-box span a {
color: #669;
}
Or, more generic:
/* Target any descendent (at any level) below anything with an id of info-box */
#info-box a {
color: #669;
}
4) If I give the #info-box a font, for example, the span and a will inherit
it from the #info-box. Anything that isn't defined in #info-box is inherited
from its parent, and so on. (this doesn't apply to link color and
text-decoration because links have some sort of special status; they're
always colored differently, so you'll have to explicitly target them in CSS)
I hope this info helps. But please make your HTML code semantically correct,
worry about targeting it with CSS later. The ids and classes should be
semantically *meaningful*, not simply aids to help you target them in CSS.
If you'd like some more pointers to websites/books to read, let me know.
Regards,
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
pgp1kSIv0c7ea.pgp
Description: PGP signature
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Experimental Chicken LiveCD
Hello folks, I've put at http://g3pd.ufpel.tche.br/chicken/ a first attempt to create a Chicken LiveCD. It's based on Knoppix. Currently there's not a lot of things. I've just removed some packages from the Knoppix CD (to free some space) and added Chicken related stuff. The LiveCD contains Chicken 2.518, a couple of eggs (listed at the end of this message), GTK Emacs and Neil Van Dyke's quack mode for Scheme, some libraries needed by some eggs and, of course, Joshua's 3D chicken as the desktop background image. :-) I intend to add some documentation and demos to the CD, besides more eggs and tools that may be useful. So, if you have: - suggestions of tools (preferably not huge in size) - simple example applications which can be used as demos for eggs - bug reports - other suggestions contact me. There's a good chance UCPel will take the thing showed at http://qdp.ucpel.tche.br (in portuguese, sorry) to FISL http://fisl.softwarelivre.org/8.0/www/?q=en). That machine is a CD burner where you can burn free software CDs. The user interface is made in Chicken, by the way. FISL may be a good oportunity to show users and developers more about Chicken. The 2007 edition counted more than 5K participants. This year we'll also have the 2nd meeting of the Brazilian Lisp Users Group (which has schemers too) and surely Chicken will be mentioned. Special thanks for UFPel folks who are providing bandwidth and disk space for making the LiveCD available. Best wishes, Mario chicken-setut -l's output APHash Version: 2.0 BKDRHash Version: 2.0 BRPHash Version: 2.0 CRCHash Version: 2.0 DEKHash Version: 2.0 DJBHash Version: 2.0 ELFHash Version: 2.0 FNVAHash Version: 2.0 FNVHash Version: 2.0 ISPLHash Version: 2.0 JSHash Version: 2.0 NDJBHash Version: 2.0 PHSFHash Version: 2.0 PJWHash Version: 2.0 PYHash Version: 2.0 RJL3Hash Version: 2.0 RJMXHash Version: 2.0 RSHash Version: 2.0 SDBMHash Version: 2.0 TWMXHash Version: 2.0 ajax Version: 1.7 alexpanderVersion: 1.58.5 ambVersion: 1.2.0 args Version: 1.1 array-libVersion: 2.0 array-lib-ec Version: 2.0 array-lib-hofVersion: 2.0 array-lib-semVersion: 2.0 array-lib-subVersion: 2.0 asxt autoload awk base64 Version: 1.3 binary-parse Version: 1.1 blas Version: 1.4 box Version: 1.4 box-mzs Version: 1.4 bshift-bresetVersion: 1.3 c3 Version: 1.0 cairo charconv Version: 1.1 checkVersion: 1.0 chicken-dump chicken-man codewalk Version: 0.4 coerce Version: 1.1 complex Version: 1.6 content-type Version: 1.2 contractsVersion: 0.2 cookie crc Version: 1.1 csv datatype
Re: [Chicken-users] Experimental Chicken LiveCD
Let me know if you want me to make any changes or to render a higher resolution version of the ``weird 3d chicken'' to better fit a desktop aspect ratio :) -Josh ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Experimental Chicken LiveCD
Hi Joshua, On Wed, 14 Feb 2007 18:03:30 -0600 Joshua Griffith [EMAIL PROTECTED] wrote: Let me know if you want me to make any changes or to render a higher resolution version of the ``weird 3d chicken'' to better fit a desktop aspect ratio :) If you could make a figure to be properly displayed at the aspect ratio corresponding to, say, 1024x768, that would be great. The chicken looks a bit fat when rescaled. :-) Best wishes, Mario ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] url egg
Hi, Looks like the url egg does not support urls with query strings. #;1 (use url) ; loading /usr/local/chicken-2.514/lib/chicken/1/url.so ... #;2 (url-string (url http://abc/def?xyz=123;)) http://abc/def; Has anyone done any workaround for this? Or should we upgrade the url egg? Thanks, Daishi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [announce] JSON egg version 2.0
Daishi Kato scripsit:
Here is an example that breaks inconsistency.
I don't think I'm happy with this.
#;18 (with-output-to-string (lambda () (json-write
(with-input-from-string [[\a\,1,2]] json-read
{\a\ : [1, 2]}
That's definitely a bug. I need to think about it to see what the
best way around it is, or if I need to change my underlying approach.
--
John Cowan [EMAIL PROTECTED] http://ccil.org/~cowan
Micropayment advocates mistakenly believe that efficient allocation of
resources is the purpose of markets. Efficiency is a byproduct of market
systems, not their goal. The reasons markets work are not because users
have embraced efficiency but because markets are the best place to allow
users to maximize their preferences, and very often their preferences are
not for conservation of cheap resources. --Clay Shirkey
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
