Re: [Chicken-users] Bug in readline 4.0 egg; missing function

[Stephen Eilert]

Would it be possible to replace readline with linenoise in your
workflow? 

http://wiki.call-cc.org/eggref/4/linenoise

 
— Stephen

On Fri, Aug 7, 2015, at 09:07 AM, Jeremy Steward wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> As of today I installed CHICKEN 4.10, and have encountered this problem
> as well. However, unlike Erik Fair, I have not even been able to install
> the egg with chicken-install.
> 
> Is there a workaround in the meantime to get this working, such as
> reverting to an older version? I find readline pretty crucial to most of
> my work flow when using CHICKEN.
> - --
> Jeremy Steward
> -BEGIN PGP SIGNATURE-
> Version: APG v1.1.1
> 
> iQJDBAEBCgAtBQJVxNfIJhxKZXJlbXkgU3Rld2FyZCA8amVyZW15QHRoYXRnZW9n
> dXkuY2E+AAoJEHVwwAZUeZnZJWMP/0coE2qWus90EywESgs4gJ7OvgL40L/ouhxd
> eVvI1gwPpVyoxK27kDfuJbJgoYKo5xEcGwX7FsqTJiHklTTbYc9O5UAcLiPTq51x
> JGMzFyb5okWR5wLPXMwKRFzNzHCaAyvMRrEmbJkd9sL9Fo/uFFTWisyWUNvoyAHp
> I960H8xjb8uQtAsQV2/V+UTZ+EFA5MU8HEmBRjStXYyXlel7tuw3NRoPfeL8M8iG
> Un2JWDZUMNit70L42YMlZQFxCKkdmbmcR+642A+h+SZ3S1yM6W0ueLFS5OZk/QO8
> WnKR7842hHu/9CYjFbnhGny5c2D35ffE1yWSQjQPaOF/AIKMtvqUyxDCV+qS8sJ4
> 7pEkHp3Ulwu/5hLkfw9aO2YzhT1FppyBApLqgyVdVxWiKA8CSuATcAUoB8IVVvlu
> lO7UQT0J2+nqtRyeOtpTpHCGG+m4fxbBSvooacALmKEzU/nVIUcsNvgmlf1c3l5H
> 5i9KGBzcksKckBnX5Au7MFpoTgt4E6eIgTET1gW5dAWwWlkssXROqUBr+Gte1Nv2
> UWRcoxxzT8ImYWxXP2AQ2a19HYPZK5bh7k2XA6315RAUPmUA2nOSlATCwy4HyOJN
> NLWsIRcGpRNPqI8qMWWxFoFBm11netixodgFAMoFARnHEP1XRWyf+U47tT0aN56n
> d53fhRdG
> =8GXB
> -END PGP SIGNATURE-
> 
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users


-- 
— Stephen

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] performance of bignums

[Stephen Eilert]

On Thu, Jun 25, 2015 at 5:53 PM, Peter Bex  wrote:

> On Thu, Jun 25, 2015 at 10:26:53PM +0200, Peter Bex wrote:
> > On Thu, Jun 25, 2015 at 05:04:17PM -0300, Stephen Eilert wrote:
> > > Not sure about the status of this particular GSOC, but SBCL could also
> be
> > > "cheating".
> > >
> > > http://www.sbcl.org/gsoc2013/ideas/#sec-1.2
> > >
> > > Now, I thought GMP were GPL'd and SBCL not, so I'm unsure about the
> legal
> > > implications, if it does bundle GMP now.
> >
> > Thanks for posting that; I hadn't looked at the sbcl implementation
> > of the pi-digits benchmark, but indeed that page says "Pi digits on
> > the benchmarks game is currently a bunch of calls to GMP".  This would
> > *really* be cheating in my opinion, as it's not testing the language
> > implementation but using nonstandard extensions that replace stuff
> > that's already part of the core.
> >
> > I had just assumed it would be using the sbcl native implementation
> > (which indeed is pretty damn good and almost 100% pure Lisp code).
>
> In fact, there are two implementations, one of which uses native
> operations.  It is still faster than CHICKEN and very close to Guile/GMP:
>
>
> http://benchmarksgame.alioth.debian.org/u32/program.php?test=pidigits&lang=sbcl&id=2#log
>
> It does use some type annotations, though.  Adding some to the
> CHICKEN version makes it go a tiny bit faster, but not by much.
>
> Cheers,
> Peter
>

That compilation output is amazing!

; note: forced to do GENERIC-* (cost 30)
;   unable to do inline fixnum arithmetic (cost 4) because:
;   The first argument is a INTEGER, not a FIXNUM.
;   The result is a (VALUES INTEGER &OPTIONAL), not a (VALUES
FIXNUM &REST T).
;   unable to do inline (signed-byte 32) arithmetic (cost 5) because:
;   The first argument is a INTEGER, not a (SIGNED-BYTE 32).
;   The result is a (VALUES INTEGER &OPTIONAL), not a (VALUES
;
(SIGNED-BYTE 32) &REST
;  T).


>From the benchmark page (
http://benchmarksgame.alioth.debian.org/u32/performance.php?test=pidigits#about
):

"In addition to language specific multiprecision arithmetic, we will accept
programs that use GMP <http://gmplib.org/>."

So, the "cheating" is official. Let's cheat too!
*I fail to see the point though. If it's a programming language shootout,
does it make sense to offload the meat of the processing to GMP?* *Do they
intend to measure the FFI performance?*


— Stephen
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] performance of bignums

[Stephen Eilert]

On Thu, Jun 25, 2015 at 4:50 PM, Peter Bex  wrote:

> On Thu, Jun 25, 2015 at 11:39:50AM -0700, Martin DeMello wrote:
> > Post to /r/scheme about chicken's bignum performance. (Not my post,
> > just figured it could use some eyeballs.)
> >
> >
> http://www.reddit.com/r/scheme/comments/3b1ujw/performance_of_chicken_scheme_numbers_bignums/
>
> Hello Martin,
>
> Thanks for posting this.  We had already been discussing it earlier
> today in #chicken.  I had another look at the code but I can't really
> find any obvious inefficiencies.  It is indeed a bit faster with
> CHICKEN 5, but not by much.
>
> Of course, Guile is "cheating" by using GMP.  If I compare it to another
> Scheme which has its own bignum implementation like Gauche, we perform
> about the same.  It's interesting that sbcl is doing so well.  Maybe I'm
> overlooking something seemingly minor but important?
>
> Cheers,
> Peter
>


Not sure about the status of this particular GSOC, but SBCL could also be
"cheating".

http://www.sbcl.org/gsoc2013/ideas/#sec-1.2

Now, I thought GMP were GPL'd and SBCL not, so I'm unsure about the legal
implications, if it does bundle GMP now.


— Stephen
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] u8vector to numbers bignum

[Stephen Eilert]

On Thu, May 28, 2015 at 9:09 PM, John Cowan  wrote:

> Peter Bex scripsit:
>
> > If this is such an important feature it may make more sense to include
> > a "proper" PRNG.
>
> Different applications will want fast crude random-ish numbers, PRNGs,
> cryptographic PRNGs, or full quantum randomness, with tradeoffs for
> speed and quality.  Since that's so, I'd rather require programmers
> to make the choice up front rather than fall back on some dubious
> OS version that does who-knows-what.
>
>
Not all applications require cryptographically secure real random number
generators. In fact, I'd argue that most random usage is not for that sort
of thing. It will be used in tutorials, or in games for a purpose such as
selecting between several available sounds. Or procedural generation if it
doesn't totally suck.

If you *are* writing something that really requires a better quality
pseudorandom generator, odds are that you will have to import one anyway.

I have no idea of what rand() uses internally, and much less what is
Chicken is actually calling on Win32. So one thing that could be of value
is not relying on the OS implementation and instead providing our own
(Mersenne Twister?). This would remove a core dependency and guarantee
consistency when running on all operating systems. Even if it is
consistently crappy(which MT doesn't appear to be, even if it should not be
used for crypto). That would be preferable, so you'd deal with it in the
beginning, instead of when porting to another OS, when you've already
forgotten all about the random generator.

For reference:
(random N)  procedure

Returns a pseudo-random integer in [0, N-1]. N is an integer.

On Windows, N and the random value are exact integer.

*Warning*: This procedure uses *rand(3)* internally and exhibits its
deficiencies, including low quality pseudo-randomness:

   - On Windows and Solaris, only 32768 unique random values can be
   generated in the range [0, N-1]. If N >= 32768, there will be gaps in
   the result set.
   - On Mac OS X, Windows and some other platforms, little variance in
   output is seen with nearby seeds. Since the random generator is seeded with
   current-seconds at startup, new processes may see similar or identical
   random sequences for up to a minute.
   - On Linux, *rand(3)* is an alias to *random(3)*, which provides output
   of reasonable quality.


— Stephen
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] ANN: new chicken-iup Windows installer with IUP gui, canvas-draw, scintilla etc. released.

[Stephen Eilert]

Just a heads up: chicken won't be able to import anything as soon as it is
installed, due to the fact that new system environment variables get added.
Logging out (or restarting) is enough to fix it.

Thanks for the work. I never had the time to get Chicken working properly
on Win32.

Now, it seems that chicken-install's proxy handling code is not working
correctly. I fixed a minor issue with it years ago, but it needs to get
smarter.


— Stephen


On Mon, May 18, 2015 at 10:23 AM, Matt Welland 
wrote:

> Oops! Thanks Mario.
>
> WHERE:
>
> http://www.kiatoa.com/fossils/chicken-iup
>
> On May 18, 2015 4:45 AM, "Mario Domenech Goulart" 
> wrote:
> >
> > Hi,
> >
> > On Sun, 17 May 2015 23:03:12 -0700 Matt Welland 
> wrote:
> >
> > > WHAT:
> > >
> > > The chicken-iup installer has been updated with Chicken 4.9.01, and
> > > recent versions of many eggs, the IUP gui including canvas-draw, and
> > > the iup scintilla editor support.
> > >
> > > STATUS:
> > >
> > > chicken-iup appears to work just fine on WinXP and Windows 8. To
> > > install eggs not bundled with the installer you will need to install
> > > mingw (http://www.mingw.org/).
> > >
> > > WHO:
> > >
> > > Thanks to Matt Gushee for his help in making this happen.
> > >
> > > WHY:
> > >
> > > I find Chicken scheme to be a pragmatic and productive development
> > > tool. The chicken-iup package makes it very easy to develop on Linux
> > > and then deploy to both Linux and Windows.
> > >
> > > Download and run the chicken-iup installer and you can start creating
> > > scripts with an IUP gui in minutes. Add mingw and you can compile your
> > > scripts to executables. Get the very easy to use Inno setup
> > > (http://www.jrsoftware.org/isinfo.php) and generate installable
> > > packages. All with almost zero integration effort. If only it was this
> > > easy on Linux
> >
> > Nice work, Matts. :-)
> >
> > Isn't a "WHERE" section missing?
> >
> > Best wishes.
> > Mario
> > --
> > http://parenteses.org/mario
> >
> > ___
> > Chicken-users mailing list
> > Chicken-users@nongnu.org
> > https://lists.nongnu.org/mailman/listinfo/chicken-users
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
>
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Basic abnf usage?

[Stephen Eilert]

Very good points. Let me add more inline noise.


On Wed, May 13, 2015 at 11:25 PM, Matt Gushee  wrote:

> Hi, Moritz--
>
> On Thu, Apr 16, 2015 at 2:35 PM, Moritz Heidkamp <
> mor...@twoticketsplease.de> wrote:
>
>>
>> sorry for the late reply, got busy :-)
>>
>
> And I'm sorry for the even later reply, got scared :-)
> No, really! It's stupid, but I am often scared of people's reactions when
> I make even mildly critical remarks (I hasten to point out that that
> feeling has nothing to do with any behavior I've observed on this mailing
> list - just my own neurosis, I guess).
>

I have the same issue, but only when I myself make overly critical remarks.
Afraid of the retorts, perhaps.


>
>> > On Sat, Mar 28, 2015 at 5:33 AM, Moritz Heidkamp <
>> mor...@twoticketsplease.de
>> >> wrote:
>>
>
>
>> > Maybe in that case it would be good if the API doc said something like:
>> > "comparse is compatible with UTF-8, but many of the built-in
>> combinators do
>> > not work with UTF-8 characters, so you may need to construct your own.
>> For
>> > example: ..."
>>
>> Sure, we can do that! I didn't mention it so far as this property is
>> implicit with how CHICKEN core strings work.
>
>
> I think you are assuming too much background knowledge. Maybe in a perfect
> world, everybody would get a CS degree, then learn all the fundamentals of
> Scheme, then master the Chicken core, then start working with extensions
> and building practical software ... but of course that's often not how it
> works in reality. And in my opinion - as someone with no formal education
> in the field, but who came to Scheme with a few years of practical
> experience in other languages - I think Scheme in general, and any given
> implementation, has a really steep learning curve. The documentation is
> good in that almost everything you need to know is covered somewhere, but
> it can also be really hard to find the information due to the extreme
> modularity and very bazaar-like culture of Scheme - docs are split up
> between r*rs and an implementation manual and extension docs written by
> different people following very different conventions. Additionally - and
> this is not anyone's fault in particular, more a side-effect of the small
> community working on Chicken - since the documentation as a whole is not
> rigorously maintained, contradictions inevitably creep in, and there are
> often several ways to do the same or similar things, with no indication of
> which is best or recommended.
>
> Sorry to rant ... I'm rather passionate about documentation. Must be my
> Python background ;-)
>

I believe I complained about this once. But I've since stopped complaining,
because I had no useful ideas on how to improve things. If you already know
what you need, things like Chickadee are awesome. If you are trying to
figure out a strange behavior, I've since learned to go back to the R5RS
docs and, if not there, look up 'deviations from the standard'. If not
there, I'll stumble through the documentation like a cockroach on meth.
Sometimes I manage to find useful information, sometimes I don't. I'd never
find out about CHICKEN core string behavior, for instance.

One idea I came up, but never implemented, was to record a list of
'documentation cache misses'. Would go like this: every time I failed to
find something in the documentation, I'd record what it was. If I really
couldn't find it, I'd ask around here or on #chicken. If noone could find
it, then I'd mark it to be inserted somewhere (or updated).


>
>
>> It's not quite that simple: Characters may be encoded in many ways,
>> UTF-8 is far from the only widely used one and not ideal in all cases,
>> e.g. the algorithmic complexity of some operations on UTF-8 encoded
>> strings is objectively worse than those on UTF-32 encoded strings. And
>> it will remain so even till the year 2050. Not guarantees on what
>> happens after that, though!
>>
>
> I'm certainly aware of different encodings - I started programming when I
> lived in Japan in the 90s, before Unicode 1.0 was finalized, and there were
> 3 major encodings in common use just for Japanese. But there is such a
> thing as 'reasonable defaults' - if you can't support all the encodings,
> what is more interoperable than UTF-8?
>

Nothing that I'm aware of. Making it the default can hurt some japanese
users, I'm told, because encoding conversion between ( - forgot what
the encoding was) and UTF-8 can be lossy.

Many implementations use UTF-16 internally(Win32 API, Java). Maybe the are
up to something, performance-wise.


>
>
>> > I'm of the opinion (shared by many I18n experts, if I'm not mistaken)
>> > that a high-level language in the 21st century should have in its core
>> > a rock-solid character abstraction that is never, ever conflated with
>> > a byte.
>>
>> The character abstraction actually is rock-solid even in CHICKEN 4
>> already: A character object represents a Unicode codepoint in an
>> encoding independent way.
>>
>
> Okay, b

Re: [Chicken-users] How to bootstrap developing a CHICKEN application?

[Stephen Eilert]

On Sun, Feb 1, 2015 at 12:25 PM, Bahman Movaqar  wrote:

>  On 02/01/2015 03:57 AM, Bahman Movaqar wrote:
>
> A naive question but suppose I want to write an application (not an
> egg); an application in the sense that it will not be installed in
> CHICKEN repository.
> What is the recommended directory structure? How can I run the tests
> (like 'chicken-install -test')? How can I express dependencies? Or is it
> just *my* conception of application and in CHICKEN there is no
> difference between this and an egg?
>
> I'd appreciate any help or a pointer to a relevant documentation.
>
>
>
> Thank you very much Peter and Mario for the detailed answers. Considering
> what you said, I believe I'll go with the "egg" approach.
>

There's also the 'system' egg, if you don't need all the goodies that an
egg can provide.


— Stephen
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Homepage design proposal - part 2

[Stephen Eilert]

On Sat, Jan 24, 2015 at 1:37 PM, Daniel Ziltener 
wrote:

> > Maybe three or four (or more!) samples depicting typical features of
> > CHICKEN. These samples could be easily "flipped" through with a few
> > navigation buttons, they would carry a clear title per sample and a few
> > comments inline of what this code is about. Programmers love to see
> > beautiful code...right?
>
> Right! I haven't seen this on pretty much any other language page yet! Most
> have a meaningless "Hello World"-code at most that doesn't say much.


Except for Python. The page is clean, pretty (IMHO) and does the job fine.
The samples are pretty small and not full programs. But all do link to the
relevant documentation section, so I guess that's useful. See:

https://www.python.org/

Which also has an interactive shell.

Scala sort of does this too (click on the boxes) below the distracting
over-the-top background imagery, section called "Scala in a Nutshell" which
often goes below the fold:

http://www.scala-lang.org/

Elixir doesn't have samples that you can flip, but you can just scroll the
page:

http://elixir-lang.org/

Go mixes the code sample and the interactive shell, has a few samples you
can load using the combobox. Page looks horrible but is works(*).

https://golang.org/

Julia´s page looks like a blog post. However, it has some pretty convincing
screenshots and code samples:

http://julialang.org/

Rust also has a pretty big code sample on its front page, that you can edit
and run.

http://www.rust-lang.org/

I was going to include Dart, but it has a screenshot of what seems to be an
Eclipse-based editor, so I'll spare you all.

Also, in case people have forgotten about it, there's Racket's homepage:

http://racket-lang.org/

With code examples that you can flip, with an "explain!" link explaining
each of them. No Daleks tho.


— Stephen

(*) Interestingly, these pages seem to reflect some of the underlying
language traits.
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Chicken Scheme's license

[Stephen Eilert]

On Tue, Jan 6, 2015 at 3:51 AM, Alexej Magura  wrote:

> Thanks, Matt.
>
>

Keep in mind that each egg is licensed separately, if that's important to
you.


— Stephen
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Installing "combinatorics" - "cock" missing

[Stephen Eilert]

On Mon, Dec 15, 2014 at 9:01 PM, Alex Shinn  wrote:
>
> On Tue, Dec 16, 2014 at 2:51 AM, Bahman Movaqar 
> wrote:
>>
>>
>> Hah!  Great guess on #chicken Mario! It was my ISP...it installed
>> smoothly after bypassing that stupid filter.  Thanks for the help.
>>
>
> There was a porn filter applied to all internet traffic which removed the
> cock egg? Wow.
>
>
I've had the same problem with apt-get once, but that was even worse: it
was trying to download libsexy. Talk about an agressive filter!


— Stephen
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] [Chicken-hackers] CHICKEN in production

[Stephen Eilert]

On Mon, Sep 29, 2014 at 6:07 PM, r  wrote:

> Hello
>
> happy to announce that we are in production with CHICKEN!
>
> Professional karaoke system AST-50 with CHICKEN driven firmware.
>
> http://www.art-system.ru/professionalnoe-karaoke/ast-50.html
>
> Feel free to ask Oleg Kolosov, Yaroslav Tsarko and me about wonderful and
> dangerous trip to the parentheses land.
>


Wow, that's even cooler than what I was expecting when I saw the email. Not
only it is 'in production', but it is a firmware too, not the average
website. Congrats :)

Now, could you pretty please with cherry on top share some details? For
instance, I saw some of the GUI in the advertisement. Is that  done in
Chicken too? Is Chicken just used as a 'glue' between modules written in
(insert whatever language here) or does it drive the whole system with
occasional C libs thrown in? How did you manage to convince management to
use Chicken? :D

Oh man, so many questions, so little time.


— Stephen
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] [ANN] New egg: glls

[Stephen Eilert]

On Wed, May 14, 2014 at 5:41 PM, Alex Charlton wrote:

> I'm pleased to announce glls: a (pseudo-)Scheme to GLSL (OpenGL Shader
> Language) compiler. Embedding GLSL shaders into your programs is now as
> easy as writing S-expressions in a Scheme file. The compilation from a glls
> definition to a GLSL shader happens at compile-time, so using glls has no
> run-time cost (aside from having it loaded into memory). Using glls gives
> your Scheme program knowledge about your shaders, so shader and program
> compilation as well as attribute and uniform location retrieval is provided
> automatically.
>
> If you're familiar with Varjo (a Common Lisp project), glls performs a
> similar task but with a more limited scope. While Varjo performs
> type-checking to validate its shaders, glls is a very literal compiler: you
> get what you write – even if you write something wrong. Errors at the GLSL
> level are therefore caught during GLSL compilation rather than during
> glls->GLSL compilation.
>
> If I may be so bold: The best has yet to come for glls. While defining
> your shaders in Scheme is convenient, the true power of this comes from
> taking advantage of what your Scheme program then knows about the shaders.
> Future work on glls will see automatic compilation of rendering functions
> for each pipeline, as well as tools for dynamic re-loading of pipelines for
> all your REPL-based shader hacking sessions.
>
> If you’re interested, check out the source:
> https://github.com/AlexCharlton/glls
>
> And the docs:
> https://wiki.call-cc.org/eggref/4/glls
>
> And if someone could add this to the egg list, I would be most
> appreciative.
>
> https://raw.githubusercontent.com/AlexCharlton/glls/master/glls.release-info
>
> Thanks!
>
>
Oh my! The documentation is huge! And with examples!

Very, very nice.


-- Stephen
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] [ANN] New egg: opengl-glew

[Stephen Eilert]

On Sun, Apr 13, 2014 at 5:12 PM, Alex Charlton wrote:

> opengl-glew provides bindings to OpenGL’s core profile while handling
> extension loading with GLEW:
>
> https://github.com/AlexCharlton/chicken-opengl-glew
>
> There are two existing eggs that have some degree of overlap with this
> one. The opengl egg provides only the older fixed function pipeline API.
> OpenGL has changed the majority of its API since then, so it’s not useful
> for writing modern graphics programs. The allegro egg provides some more
> recent OpenGL bindings (they seem to have been last updated in 2012), but
> relies on Allegro which not everyone wants as a dependency.
>
> opengl-glew uses the widely used GLEW to handle its extension loading,
> making this egg immediately useful to most programmers who work with modern
> OpenGL. Further, it is guaranteed to always be up-to-date with the latest
> OpenGL core profile, because it downloads the glcorearb header file from
> opengl.org and uses it to generate its bindings. Some high-level
> convenience functions are also provided.
>
> Mario, could you please add this to the egg list:
>
>
> https://raw.githubusercontent.com/AlexCharlton/chicken-opengl-glew/master/opengl-glew.release-info
>
> Thanks!
>
>
This is awesome! Thank you :)


-- Stephen
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] chicken-iup - progressing nicely but have problem with canvas-draw

[Stephen Eilert]

On Tue, Feb 4, 2014 at 12:13 PM, John Cowan  wrote:

> What do you think of my idea of dropping even GNU make for MSVC support
> and just compiling everything with a batch file?  One thing I note is
> that MSVC's C compiler is C89 only; do we have dependencies on post-C89
> syntax either in Chicken itself (which presumably could be worked around)
> or in the generated code?
>

Oh! That's true, I had forgotten all about it. Microsoft's recommendation
is to compile C code with the C++ compiler. This may or may not work,
depending on what Chicken is using.

GNU Make is an annoying dependency on Windows, but batch files are way too
ugly. If and only if we take that route, may I suggest Powershell? It is
found on all 'modern' (>= XP) windows installs and is much more powerful
(it can even load and call .net assemblies, for instance). That would make
it less insane.

CMake is also annoying, but it works.


-- Stephen
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] chicken-iup - progressing nicely but have problem with canvas-draw

[Stephen Eilert]

On Mon, Feb 3, 2014 at 1:02 PM, Peter Bex  wrote:

> On Mon, Feb 03, 2014 at 01:58:31PM -0200, Stephen Eilert wrote:
> > I think the issue is that Chicken for the moment does not seem to enjoy
> > much popularity on Windows. Having an installer could help mitigate some
> of
> > that, but I am not sure it's the only requirement. Perhaps being able to
> > compile with Microsoft's C compile would be better to ensure
> compatibility
> > with existing libraries? I took a stab at it some time ago and found the
> > build system to be a major pain, so I dropped the project.
>
> Are you referring to our build system or the MSVC tools?  If the former,
> I wouldn't mind answering some questions about it.  I know it has some
> complicated Make macrology, but it's better than spelling out each rule
> in full.
>

Oh, don't get me wrong, I have no issues with it as an user (or even doing
minor changes on *nix). However, understanding and translating those rules
to Microsoft's tools required more sanity than I had available (or less
sanity, I can't tell!).


-- Stephen
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] chicken-iup - progressing nicely but have problem with canvas-draw

[Stephen Eilert]

On Sat, Feb 1, 2014 at 11:32 PM, Matt Welland  wrote:

> Ok, no takers on my lame attempt at a financial bribe for making the next
> chicken-iup so I took a stab at it myself. I've made pretty good progress,
> no doubt thanks to all the great work done by the Chicken devs, so far
> chicken 4.8.0.5 and iup have compiled and seem to run fine. I'm stuck at
> getting the canvas-draw egg installed. Does the error below mean anything
> to anyone? Thanks.
>
> Note: one thing I did different is apply a patch to ffcall that claims to
> fix the trampoline conflict with windows executable protection. ffcall
> compiled fine and I doubt it is related to this issue but I thought I'd
> mention it.
>
>
I think the 'bribe' did not have anything to do with it. Some of us will
gladly improve Chicken without any financial reward - but having a 'bounty'
for open issues doesn't seem like a bad idea. Heck, I'd do it in exchange
for booze! :)

I think the issue is that Chicken for the moment does not seem to enjoy
much popularity on Windows. Having an installer could help mitigate some of
that, but I am not sure it's the only requirement. Perhaps being able to
compile with Microsoft's C compile would be better to ensure compatibility
with existing libraries? I took a stab at it some time ago and found the
build system to be a major pain, so I dropped the project.

That said, do you mind if I ask you what is it that you are working on
which requires Windows? :)


-- Stephen
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Need to do an install, any changes in the pipe line I should wait for?

[Stephen Eilert]

On Sun, Nov 10, 2013 at 7:37 PM, Peter Bex  wrote:

> On Sun, Nov 10, 2013 at 10:31:33PM +, Mario Domenech Goulart wrote:
> > Eggs don't specify the exact version of dependencies they need.  You can
> > specify a requirement like "at least ", but not "exactly
> ".
> >
> > So, as far as I can see, you always have a consistent set, unless eggs
> > (or chicken-install) are broken.
>
> Maybe I'm missing something (I haven't been paying very close attention
> to this thread), but if you request an ancient version of spiffy it's
> probably not going to work with the latest intarweb.  The meta files
> can't express this, because that would be knowing what future versions
> of an extension will break your code.
>
> Bundler has fancy ways of specifying exactly what version of each egg
> you want, but IIRC by default it just "nails down" the exact versions
> you have installed right now.  This means you get an easy way to
> reproduce the exact current situation.
>

I think a 'bundler'-like tool is a necessary evil, if one wishes to
maintain an application for a few years - and it would be convenient as
well in other cases. I took a stab at implementing one back in May, but as
usual things came up and I never finished.

The idea was:

- User creates a 'hatchfile' listing all the eggs the application needs. At
this point, versions are optional.

- Instead of calling chicken-install directly for each missing egg, the
tool would read the file and ask chicken-install to fetch and install them.

- The tool would record the egg versions (somewhere!) in order to 'freeze'
them. Further installs wouldn't fetch new versions, unless an upgrade was
requested.

Note that, at the time, I didn't know about egg-pack-sources, so I didn't
consider it. Indeed, 'vendoring' the eggs might be a better solution. It
would really guarantee that they are available and that they work. I'll
have to play with that.

Depending on how the environment is setup, there is still the possibility
of egg version conflicts among different applications, if they are
installed system-wide, in the default repository. Which is usually the case.

I'm not too fond of how tools like RVM handle that, convenient as they are.
Thankfully, since Chicken reads the CHICKEN_REPOSITORY environment
variable, it is an easy fix.


-- Stephen
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] replacement for rlwrap on MS Windows, MinGW

[Stephen Eilert]

On Fri, Jul 19, 2013 at 3:42 PM, Claude Marinier wrote:

> Bonjour,
>
> Console2 (see URL below) is a reasonable replacement for 'rlwrap' or
> 'rlfe' when using csi on MS Windows, MinGW. Go to Edit / Settings and
> change the shell to csi.
>
> http://sourceforge.net/projects/console/
>
> Actually, it's not that good. Does anyone have a good replacement for
> 'rlwrap' ? or something like Console2 but better suited?
>
> I heard emacs and slime can do this but that is intimidating for an old vi
> user.
>
> Merci.
>
> P.S. I know I could use Cygwin.
>
>
I thought that Console2's development had been stopped.

In any case, if you are looking for a better shell replacement, try ConEmu.
It has everything that you could possibly want, even a quake-like console,
text progress bar detection, tabs, copy and paste (with the right mouse
button!) etc. Also, install Clink for the shell itself.

https://code.google.com/p/conemu-maximus5/

I have yet to try running CSI under it, but will probably do it later.


-- Stephen
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Wish list

[Stephen Eilert]

On Wed, Feb 13, 2013 at 4:27 PM, Mario Domenech Goulart <
mario.goul...@gmail.com> wrote:

> On Wed, 13 Feb 2013 16:18:31 -0300 Stephen Eilert 
> wrote:
>
> > My opinion is that the default repository should live under the
> > current user's home directory (.chicken ?), so that no super-user
> > permissions are necessary for installing eggs on development
> > machines. Deployment setups could use a system-wide repo, as desired,
> > or even bundle eggs with the deployed application. This would even
> > allow multiple chicken versions to co-exist in the same machine
> > (which is already possible, but requires some environment variable
> > magic).
>
> Maybe http://wiki.call-cc.org/eggref/4/chicken-belt#chicken-select ?


I'll have a look.


-- Stephen
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Wish list

[Stephen Eilert]

On Sun, Feb 10, 2013 at 3:36 PM, Aleksej Saushev  wrote:

>   Hello,
>
> I have talked to a user, and he reminded me of my past experience of
> using Chicken in production environment around four years ago. While
> many things improved since then, there're still some I'd like to have.
>
> 1. Distribute eggs by HTTP(S) and/or FTP(S).
>
> Today I have "chicken-install -r", but it still is a specialized client.
> I don't quite understand what I can do if I'm in mildly hostile network
> where automatically configured proxy requires authentication mechanism
> chicken-install doesn't support.
>

I have added some support for http proxies to chicken-install a long time
ago. It does not support HTTP authentication, but it shouldn't be more than
a couple of hours of work to add the required support. It would be trivial
to add, except that chicken-install cannot itself rely on eggs to perform
the work.

I am no longer inside a proxy, so the motivation for doing that evaporated.
How many people are using Chicken behind corporate proxies?


>
> 4. Support installation of eggs into directory other than
> $(chicken-install -repository).
>
> It would be nice to be able to install eggs into private area
> (for testing purposes, for migration purposes, just as developer
> convenience, whatever).
>
>
This is supported already as others have pointed out, it's just not the
default.

My opinion is that the default repository should live under the current
user's home directory (.chicken ?), so that no super-user permissions are
necessary for installing eggs on development machines. Deployment setups
could use a system-wide repo, as desired, or even bundle eggs with the
deployed application. This would even allow multiple chicken versions to
co-exist in the same machine (which is already possible, but requires some
environment variable magic).


-- Stephen
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] How Lisp is going to save the world

[Stephen Eilert]

Just saw this on Hacker News and found it awesome. The Scheme Guild is in
there too!

http://landoflisp.com/#guilds

HN thread:

http://news.ycombinator.com/item?id=5030803


-- Stephen


*"Kids these days.*
*Whatever happened to hard work?"*

   -- Joel Spolsky, The perils of javaschools
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] CSC -embedded

[Stephen Eilert]

I'll try to create a simple test case to demonstrate the problem. It will
take a few days, as there's a holiday here and I won't be touching
computers much.


-- Stephen

*"Kids these days.*
*Whatever happened to hard work?"*

   -- Joel Spolsky, The perils of javaschools



On Thu, Nov 15, 2012 at 6:50 AM, Christian Kellermann
wrote:

> * Stephen Eilert  [121115 04:19]:
> > Hello again,
> >
> > I have tried compiling a scheme program, using both csc -e and csc
> > -embedded in order to tell it not to generate a main() function, but it
> > does it anyway. I was trying to generated a mainless .c file to embed
> > inside another app.
> >
> > -DC_EMBEDDED does the trick, though. Was the option removed from csc?
>
> As I understand it, csc will invoke the linker with your scheme code
> *and* your c files. So you would have to provide the main() function
> there:
>
> csc -embedded t.scm main.c --> t executable.
>
> To help you further there I would need to know more about your
> problem.
>
> HTH,
>
> Christian
>
> --
> In the world, there is nothing more submissive and weak than
> water. Yet for attacking that which is hard and strong, nothing can
> surpass it. --- Lao Tzu
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Chicken Scheme for mobile devices?

[Stephen Eilert]

I have added the code I created last year to my github repository. It can
be found at https://github.com/outworlder/beamrider

This is just to give an idea of how I've made it work. It has since
succumbed to bit rot and is segfaulting for some reason I haven't tracked
down yet - something to do with the initial_trampoline. It is also a nice
example of what NOT to do (copying files from Chicken's distribution, for
instance).

The nice thing is that the rendering loop just calls the Scheme code, which
in turn does the drawing with OpenGLES. Last time I tested it, it worked
beautifully. The remote-repl is temporarily disabled, but I could mess
around and change the rendering in the device by connecting to it remotely.

The OpenGL ES code was poached (without attribution, yet) from jlongster, I
think - I didn't intend to release it at first - and I've added some
horrible macro trickery in order not to modify the source file (much, I've
changed pointer to c-pointer in some places) in order to use Gambit's FFI
directly.

I think it is an ugly hack, but we can definitely improve on it.


-- Stephen

*"Kids these days.*
*Whatever happened to hard work?"*

   -- Joel Spolsky, The perils of javaschools



On Wed, Nov 14, 2012 at 3:49 PM, Kevin Wortman  wrote:

> I am interested in this as well. I've only investigated Android and iOS
> and can't speak to other mobile platforms. There are two obstacles, 1)
> getting Scheme code to run on target platforms, and 2) exposing the APIs
> for UI, GPS, etc. to the Scheme world.
>
> One solution to (1), as Stephen described, is to use csc to compile Scheme
> to C then compile that C according to the vendor-sanctioned process. C
> plays nicely with Xcode Objective C projects, and Android provides the NDK
> environment. So you can get Scheme compiled to good native code. However
> (2) is a  problem since the iOS APIs are Objective C and AFAIK Chicken code
> cannot currently call into that. On paper the Android NDK looks like it
> should work, but the docs are quite clear that it's not intended to wrap
> the entire Android API and so may not be complete or future proof.
>
> These problems could be overcome by creating a general purpose
> Scheme-to-Java FFI and giving the Scheme-to-ObjC FFI some love. But those
> are big undertakings and may be overgeneralization.
>
> Both Android and iOS support OpenGL ES and libsdl, and we already have SDL
> and OpenGL (non-ES) binding eggs. So the path of least resistance for
> game-like apps that only need OpenGL and SDL functionality may be to use
> only those. We could create a build tool that automates the process of
> building those eggs, their dependencies, and client Scheme code, writes
> ObjC/Java shims, and integrates everything into the target build
> environments.
>
> A very different approach is to build web apps. We can use Spock to
> compile Scheme to JavaScript. There are well documented processes for
> bundling HTML5 pages into redistributable apps. Scheme can call into the
> HTML5 API, which others have already designed as a thorough and
> cross-platform API for this sort of thing. This approach seems to be
> aligned with the interests and wishes of Apple and Google and so may be
> cleaner and more future proof. However there is a performance penalty from
> running interpreted JS. And IIRC Spock supports a limited subset of
> bigchicken and cannot load eggs. So the Scheme environment would be limited.
>
> I am most interested in games and game-like apps, so I am willing to make
> some simplifying assumptions. Is that true for others, or do people want to
> support cross platform native apps in their full generality?
>
> Regards,
> Kevin Wortman
>
>
>
>
> On Wed, Nov 14, 2012 at 6:37 AM, Stephen Eilert wrote:
>
>>  Yes, please. I've been toying with this idea for quite a while now.
>>
>> Chicken already works without modification on iOS. However, since you
>> cannot link to third party libraries dynamically, you'd have to compile two
>> versions (x86 one for the simulator, ARM version for the device) and
>> statically link to the correct version.
>>
>> What I have done previously (successfully), was to grab the generated C
>> Chicken (runtime.c, srfi-1.c, ports.c, etc) and added to the XCode project.
>> Then, I compiled my program and asked csc to just dump the .c files. I then
>> added it to the project as well. Also added a Makefile so that they would
>> get recompiled as necessary.
>>
>> That worked, I was even able to open a remote REPL and make changes and
>> have them displayed in the device (the OpenGLES drawing code was written in
>> Scheme). The advantage of this approach was that one doesn't need to ca

[Chicken-users] CSC -embedded

[Stephen Eilert]

Hello again,

I have tried compiling a scheme program, using both csc -e and csc
-embedded in order to tell it not to generate a main() function, but it
does it anyway. I was trying to generated a mainless .c file to embed
inside another app.

-DC_EMBEDDED does the trick, though. Was the option removed from csc?


-- Stephen

*"Kids these days.*
*Whatever happened to hard work?"*

   -- Joel Spolsky, The perils of javaschools
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Installing the SDL Egg on OSX Montain Lion

[Stephen Eilert]

On Wed, Nov 14, 2012 at 11:40 AM, Christian Kellermann
wrote:

> * Stephen Eilert  [121114 02:30]:
> > Hello guys,
> >
> > Before I don the full diving suit, I'd like to know if any of you have
> > pointers regarding building the SDL egg on OSX.
> >
> > I am doing some experiments which depend on SDL and Cairo which are both
> > easy to install under Linux. But this is my main dev machine and I'd
> really
> > like to get it working properly.
> >
> > Cairo was complaining about xcb-shm or something, which I fixed by
> setting
> > PKG_CONFIG_PATH=/usr/X11/lib/pkgconfig
> >
> > No such luck with SDL. I have tried installing and linking SDL with
> > homebrew (actually, all packages with SDL on their names, to be sure:
> brew
> > install sdl sdl_gfx sdl_image sdl_mixer sdl_net sdl_rtf sdl_sound
> sdl_ttf),
> > then compiling the SDL egg. It gives me the linker errors below.
> >
> > I wondered if it was an arch problem, but it seems that both chicken and
> > the library are x86-64. For instance:
> >
> > ???  file /usr/local/Cellar/sdl_net/1.2.8/lib/*
> > /usr/local/Cellar/sdl_net/1.2.8/lib/libSDL_net-1.2.0.dylib: Mach-O 64-bit
> > dynamically linked shared library x86_64
> > /usr/local/Cellar/sdl_net/1.2.8/lib/libSDL_net.a:   current ar
> > archive random library
> > /usr/local/Cellar/sdl_net/1.2.8/lib/libSDL_net.dylib:   Mach-O 64-bit
> > dynamically linked shared library x86_64
> >
> >
> > So I am not sure what the problem is. Any ideas?
> >
>
> Just a small note: The sdl egg is also available as sdl-base, sdl-ttf,
> sdl-net, etc. so if you don't need everything you can concentrate on
> the parts you actually need. The sdl egg has been left as is for
> backwards compatibility.
>

Thanks for the help guys. I only need sdl-base for now (later on, sdl-ttf
will be required) and installing just sdl-base worked (compiled and
linked). I am getting a NSInternalConsistencyException now but I recall
reading something about it in the documentation.

sdl_net was already linked to /usr/local/lib, so I am not sure what went
wrong, I will investigate when I get more free time. My feeling is that
there are some missing functions (maybe due to the version I have?), I'll
dump the symbols to check.

Also, pkg-config output:

$  pkg-config --libs sdl
-Wl,-framework,Cocoa -L/usr/local/lib -lSDLmain -lSDL



-- Stephen

*"Kids these days.*
*Whatever happened to hard work?"*

   -- Joel Spolsky, The perils of javaschools
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Chicken Scheme for mobile devices?

[Stephen Eilert]

 Yes, please. I've been toying with this idea for quite a while now.

Chicken already works without modification on iOS. However, since you
cannot link to third party libraries dynamically, you'd have to compile two
versions (x86 one for the simulator, ARM version for the device) and
statically link to the correct version.

What I have done previously (successfully), was to grab the generated C
Chicken (runtime.c, srfi-1.c, ports.c, etc) and added to the XCode project.
Then, I compiled my program and asked csc to just dump the .c files. I then
added it to the project as well. Also added a Makefile so that they would
get recompiled as necessary.

That worked, I was even able to open a remote REPL and make changes and
have them displayed in the device (the OpenGLES drawing code was written in
Scheme). The advantage of this approach was that one doesn't need to care
what the target device is. However, it is too 'hackish' for my tastes. Not
to mention that it would be a pain to add eggs. But it proved that Chicken
works fine on iOS.

Since one can call Scheme functions from C, it is trivial to do so using
Objective-C. The other way around should be possible too, but I haven't
poked too much into Objective-C's internals yet. If all else fails, we
could always write 'foreign code'.

Building a cross compiler (and using the correct one in the iOS build
system) is rather tedious, as is statically linking the correct eggs. If we
had a tool to generate a 'template' project and maintain it, we'd have a
winner. Actually building it could be accomplished by xcodebuild, as long
as we add a build step that calls csc.

I'm talking about iOS since that's what I am used to, but this could be
even better under, say, Android. Anyone knows what the state of the NDK
nowadays? Would we be able to create apps in mostly Scheme?


-- Stephen

*"Kids these days.*
*Whatever happened to hard work?"*

   -- Joel Spolsky, The perils of javaschools



On Tue, Nov 13, 2012 at 4:09 PM, Andrew Pennebaker <
andrew.penneba...@gmail.com> wrote:

> I see the beginnings of a Chicken Scheme port for Android:
>
> https://github.com/kristianlm/chicken-android
>
> I'd like to see ports for other mobile platforms (iOS, Windows Phone,
> Windows Surface). I'd prefer to write my mobile apps all in one FPL, and
> Chicken Scheme would be a fantastic choice.
>
> I'd also like to see more effort put into simplifying the
> build-to-mobile-app process. csi/csc are incredibly easy and intuitive, and
> I'd like to see a similar tool for one-step building runnable mobile apps
> from Chicken Scheme code. Maybe call it csm (Chicken Scheme Mobile)?
>
> Anyone interested?
>
> --
> Cheers,
>
> Andrew Pennebaker
> www.yellosoft.us
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
>
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] Installing the SDL Egg on OSX Montain Lion

[Stephen Eilert]

Hello guys,

Before I don the full diving suit, I'd like to know if any of you have
pointers regarding building the SDL egg on OSX.

I am doing some experiments which depend on SDL and Cairo which are both
easy to install under Linux. But this is my main dev machine and I'd really
like to get it working properly.

Cairo was complaining about xcb-shm or something, which I fixed by setting
PKG_CONFIG_PATH=/usr/X11/lib/pkgconfig

No such luck with SDL. I have tried installing and linking SDL with
homebrew (actually, all packages with SDL on their names, to be sure: brew
install sdl sdl_gfx sdl_image sdl_mixer sdl_net sdl_rtf sdl_sound sdl_ttf),
then compiling the SDL egg. It gives me the linker errors below.

I wondered if it was an arch problem, but it seems that both chicken and
the library are x86-64. For instance:

⌘  file /usr/local/Cellar/sdl_net/1.2.8/lib/*
/usr/local/Cellar/sdl_net/1.2.8/lib/libSDL_net-1.2.0.dylib: Mach-O 64-bit
dynamically linked shared library x86_64
/usr/local/Cellar/sdl_net/1.2.8/lib/libSDL_net.a:   current ar
archive random library
/usr/local/Cellar/sdl_net/1.2.8/lib/libSDL_net.dylib:   Mach-O 64-bit
dynamically linked shared library x86_64


So I am not sure what the problem is. Any ideas?

--

⌘  chicken-install sdl
retrieving ...
connecting to host "chicken.kitten-technologies.co.uk", port 80 ...
requesting "/henrietta.cgi?name=sdl&mode=default" ...
reading response ...
HTTP/1.1 200 OK
Date: Wed, 14 Nov 2012 01:27:33 GMT
Server: Apache/2.2.19 (Unix) mod_ssl/2.2.19 OpenSSL/0.9.9-dev DAV/2
SVN/1.6.17 PHP/5.2.17 mod_fastcgi/2.4.6
Connection: close
Transfer-Encoding: chunked
Content-Type: text/plain
reading chunks 
reading files ...
  ./Makefile
  ./COPYING
  ./test-heap.scm
  ./heap.scm
  ./keysym.scm
  ./sdl-csi.scm
  ./sdl.meta
  ./sdl.scm
  ./sdl.setup
  ./test-sdl-body.scm
  ./test-net.scm
  ./unknown2-scale8.jpg
  ./test-sdl.scm
  ./timer.scm
 sdl located at
/var/folders/bj/zgyqckpd3pscphz33fc9sny0gn/T/tempaf86.28431/sdl
checking platform for `sdl' ...
checking dependencies for `sdl' ...
install order:
("sdl")
installing sdl:0.5.5 ...
changing current directory to
/var/folders/bj/zgyqckpd3pscphz33fc9sny0gn/T/tempaf86.28431/sdl
  /usr/local/Cellar/chicken/4.8.0/bin/csi -bnq -setup-mode -e
"(require-library setup-api)" -e "(import setup-api)" -e
"(setup-error-handling)" -e "(extension-name-and-version '(\"sdl\"
\"0.5.5\"))"
/var/folders/bj/zgyqckpd3pscphz33fc9sny0gn/T/tempaf86.28431/sdl/sdl.setup
  /usr/local/Cellar/chicken/4.8.0/bin/csc -feature compiling-extension
-setup-mode-s -O3 -d1 sdl.scm -j sdl -lSDL  -I/usr/local/include/SDL
 -D_GNU_SOURCE=1  -D_THREAD_SAFE   -L/usr/local/lib  -lSDLmain  -lSDL  -C
-Wl,-framework,Cocoa
clang: warning: -Wl,-framework,Cocoa: 'linker' input unused when '-c' is
present
sdl.c:1315:35: warning: passing 'unsigned char *' to parameter of type
'char *' converts between pointers to integer types with different sign
[-Wpointer-sign]
C_r=C_mk_bool(SDL_VideoDriverName(t0,t1));
~~^~~
/usr/local/Cellar/chicken/4.8.0/include/chicken/chicken.h:972:38: note:
expanded from macro 'C_mk_bool'
#define C_mk_bool(x)   ((x) ? C_SCHEME_TRUE : C_SCHEME_FALSE)
 ^
/usr/local/include/SDL/SDL_video.h:284:58: note: passing argument to
parameter 'namebuf' here
extern DECLSPEC char * SDLCALL SDL_VideoDriverName(char *namebuf, int
maxlen);
 ^
1 warning generated.
Undefined symbols for architecture x86_64:
  "_IMG_Load", referenced from:
  _f_9949 in sdl.o
  _f_9959 in sdl.o
  "_SDLNet_AddSocket", referenced from:
  _f_10561 in sdl.o
  "_SDLNet_CheckSockets", referenced from:
  _stub4005 in sdl.o
  "_SDLNet_DelSocket", referenced from:
  _f_10583 in sdl.o
  "_SDLNet_Init", referenced from:
  _f_10220 in sdl.o
  "_SDLNet_Quit", referenced from:
  _f_10224 in sdl.o
  "_SDLNet_ResolveHost", referenced from:
  _f_10233 in sdl.o
  _f_10240 in sdl.o
  "_SDLNet_ResolveIP", referenced from:
  _f_10263 in sdl.o
  "_SDLNet_TCP_Accept", referenced from:
  _f_10333 in sdl.o
  "_SDLNet_TCP_Close", referenced from:
  _f_10442 in sdl.o
  "_SDLNet_TCP_GetPeerAddress", referenced from:
  _f_10362 in sdl.o
  "_SDLNet_TCP_Open", referenced from:
  _f_10308 in sdl.o
  "_SDLNet_TCP_Recv", referenced from:
  _f_10412 in sdl.o
  "_SDLNet_TCP_Send", referenced from:
  _f_10383 in sdl.o
  "_TTF_CloseFont", referenced from:
  _f_9498 in sdl.o
  "_TTF_FontAscent", referenced from:
  _f_9557 in sdl.o
  "_TTF_FontDescent", referenced from:
  _f_9570 in sdl.o
  "_TTF_FontFaceFamilyName", referenced from:
  _f_9626 in sdl.o
  "_TTF_FontFaceIsFixedWidth", referenced from:
  _f_9609 in sdl.o
  "_TTF_FontFaceStyleName", referenced from:
  _f_9643 in sdl.o
  "_TTF_FontFaces", referenced from:
  _f_9

Re: [Chicken-users] Building Chicken Scheme for Android

[Stephen Eilert]

On Tue, Oct 2, 2012 at 8:01 AM, Kristian Lein-Mathisen <
kristianl...@gmail.com> wrote:

> If you just compile a C file an run it on your phone, you can check out how
> the csi 
> binary is
> built. The building 
> section describes
> how you can place this on your phone and run (I don't recall if this
> actually requires root access). This is with the ndk still.
>

One could also embed Chicken inside his own app and open a socket to a
REPL. Not sure if there are any Android-specific issues, but I've done that
with an iOS application.



-- Stephen

*"Kids these days.*
*Whatever happened to hard work?"*

   -- Joel Spolsky, The perils of javaschools
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] OCD Egg

[Stephen Eilert]

On Sat, Sep 15, 2012 at 3:01 PM, Mario Domenech Goulart <
mario.goul...@gmail.com> wrote:

> On Sat, 15 Sep 2012 14:25:28 -0300 Stephen Eilert 
> wrote:
>
> > I know it's been a while, I've been quite busy the last few months.
> > Unfortunatly, that's not Chicken-related :(
> >
> > However, I want to redeem myself. Therefore, I am requesting comments on
> a
> > simple egg I've made. It is not yet what you would consider "stable",
> but I am
> > already using it for some time now to develop my projects.
> >
> > For those who know them, it is similar to 'autotest' or 'guard'. That
> is, it
> > scans the filesystem and runs a command whenever the files it is
> interested in
> > have changed. This is useful specially for those who like to code using
> tests.
> >
> > Its default behaviour is to scan for .scm files in the current directory
> and,
> > whenever any files have changed their timestamps, it tries to run a
> Makefile.
> > You can customize it somewhat with a .ocdrc file, in order to filter a
> > different file set, or run a different command when they have changed.
> You can
> > force a run by hitting Control+C, or abort it hitting Control+C twice.
> >
> > It is currently missing support for inotify (or fsevent under OSX), so
> it needs
> > to poll the filesystem (by default, every two seconds). This might be a
> problem
> > for large projects, but so far this has not bothered me much.
> >
> > So, what do you guys think? I intend to improve it some more if at least
> one
> > more person finds it useful :)
> >
> > This is the repository: https://github.com/outworlder/OCD
>
> Looks very nice, Stephen.
>
> There's some chicken code for inotify at
> https://github.com/xlevus/chicken-stuff/blob/master/inotify.scm , in
> case you want to support it.
>
> Anyway, if it works and it is useful to you, why not add it to the egg
> repository?
>
>
Will do it later today :)



-- Stephen
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] OCD Egg

[Stephen Eilert]

Hello guys,

I know it's been a while, I've been quite busy the last few months.
Unfortunatly, that's not Chicken-related :(

However, I want to redeem myself. Therefore, I am requesting comments on a
simple egg I've made. It is not yet what you would consider "stable", but I
am already using it for some time now to develop my projects.

For those who know them, it is similar to 'autotest' or 'guard'. That is,
it scans the filesystem and runs a command whenever the files it is
interested in have changed. This is useful specially for those who like to
code using tests.

Its default behaviour is to scan for .scm files in the current directory
and, whenever any files have changed their timestamps, it tries to run a
Makefile. You can customize it somewhat with a .ocdrc file, in order to
filter a different file set, or run a different command when they have
changed. You can force a run by hitting Control+C, or abort it hitting
Control+C twice.

It is currently missing support for inotify (or fsevent under OSX), so it
needs to poll the filesystem (by default, every two seconds). This might be
a problem for large projects, but so far this has not bothered me much.

So, what do you guys think? I intend to improve it some more if at least
one more person finds it useful :)

This is the repository: https://github.com/outworlder/OCD


-- Stephen

*"Kids these days.*
*Whatever happened to hard work?"*

   -- Joel Spolsky, The perils of javaschools
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Building Chicken on OS X Lion

[Stephen Eilert]

Have you got homebrew? It just works for me.

==> Downloading
http://code.call-cc.org/releases/4.7.0/chicken-4.7.0.6.tar.gz

100.0%
==> make PREFIX=/usr/local/Cellar/chicken/4.7.0.6 PLATFORM=macosx
C_COMPILER=cc ARCH=x86-64
==> make install PREFIX=/usr/local/Cellar/chicken/4.7.0.6 PLATFORM=macosx
C_COMPILER=cc ARCH=x86-64
/usr/local/Cellar/chicken/4.7.0.6: 106 files, 16M, built in 2.8 minutes


-- Stephen

*"Kids these days.*
*Whatever happened to hard work?"*

   -- Joel Spolsky, The perils of javaschools



On Fri, Aug 31, 2012 at 9:31 AM, Hans Nowak  wrote:

> Hi,
>
> I am still having problems building/installing Chicken on OS X Lion, even
> with the new version 4.7.0.6 and 4.8rc2.
>
> Here is a paste of the output when I do make install; it hangs at "loading
> import libraries".
>
> http://paste.call-cc.org/**paste?id=**a7fd2260fb3540a24db2fbd703607a**
> 0555446589
>
> I am probably doing something wrong, or have the wrong version of
> something or another, but what?
>
> Any tips welcome.
>
> Thanks,
>
> --
> Hans Nowak
>
>
> __**_
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/**mailman/listinfo/chicken-users
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] ANN: Lowdown, a pure Chicken Markdown parser

[Stephen Eilert]

On Mon, Aug 6, 2012 at 4:49 PM, Peter Bex  wrote:

> On Mon, Aug 06, 2012 at 04:40:44PM -0300, Stephen Eilert wrote:
> > Cool!
> >
> > I must apologize, btw. I was written something that required a Markdown
> > parser and I didn't feel like going on this huge detour to write a
> Markdown
> > parser in Scheme, so I just used the Discount library and that's it.
>
> That's perfectly fine.  Writing a parser yourself is a lot of work, and
> you probably had bigger fish to fry at the time.  Remember, Chicken is
> *practical* Scheme system.  We get shit done around here!
>
> > And reading and emitting strings is actually a nicer interface than what
> you'd
> > normally write with Discount - took me a while to backtrack and redo it,
> it
> > was going to be something much more complex to begin with.
> >
> > In any case, I am not to sad to see the Discount egg die. Give it an
> > horrible death.
>
> If this is how you feel about the egg, I think it's probably a good idea
> to change its category to "deprecated", and put a note on the wiki page
> pointing people to the lowdown egg.  This provides some transparency
> about the egg's status, and guides people's expectations.
>
>
I don't hate it. However, since we have a pure Chicken version, I see no
reason to have it around.

Unless it turns out there are people besides me using it. In that case, I
could give it some love.


-- Stephen
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] ANN: Lowdown, a pure Chicken Markdown parser

[Stephen Eilert]

On Sun, Aug 5, 2012 at 2:27 PM, Moritz Heidkamp
wrote:

> Fellow Chickeneers,
>
> yesterday I released the first version of Lowdown, a Markdown parser
> written in pure Chicken Scheme. The only other Markdown parser egg we
> had so far, discount, requires the corresponding C library and can only
> read and emit strings. Lowdown doesn't have any foreign dependencies,
> can read from strings or input ports (well, any lazy-seq of chars,
> really) and emits SXML. It passes all 22 tests of MarkdownTest version
> 1.0.3. I also started implementing a very basic extension API but that's
> not ready for public consumption, yet. For more information, check the
> documentation at the usual place: http://wiki.call-cc.org/eggref/4/lowdown
>
> Hope it's useful to anyone!


Cool!

I must apologize, btw. I was written something that required a Markdown
parser and I didn't feel like going on this huge detour to write a Markdown
parser in Scheme, so I just used the Discount library and that's it. And
reading and emitting strings is actually a nicer interface than what you'd
normally write with Discount - took me a while to backtrack and redo it, it
was going to be something much more complex to begin with.

In any case, I am not to sad to see the Discount egg die. Give it an
horrible death.


-- Stephen
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] [ANN] chicken-belt 0.0.6: Introducing chicken-hatch

[Stephen Eilert]

On Sun, May 20, 2012 at 5:42 PM, Moritz Heidkamp  wrote:

> Fellow Chickeneers,
>
> I would like to announce version 0.0.6 of the chicken-belt egg. The main
> novelty is the chicken-hatch program which should come in handy when
> creating new eggs. It interactively asks for a few things such as egg
> category (by presenting a list to choose from - this should hopefully
> reduce the use of invalid egg categories) and generates a skeleton egg
> directory from that. Its feature set is currently very minimal but I
> hope it's already somewhat useful!
>
>
Fantastic :)I've had this idea before, but ideas are worth nothing unless
implemented.

Can we run it under an existing directory? If, for instance, we have a
program we'd like to "eggfy".


-- Stephen

*"Kids these days.*
*Whatever happened to hard work?"*

   -- Joel Spolsky, The perils of javaschools
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Building a web store in Chicken scheme

[Stephen Eilert]

On Tue, May 8, 2012 at 9:30 AM, yuval  wrote:

> First question If I will use the chicken scheme fastcgi Is it possible to
> find a cheap deployment host on the Internet.


Nowadays, this is not much of a problem. There are many options, such as
Heroku or Amazon EC2 instances (*almost* free under the free tier).


-- Stephen
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Chicken on Heroku

[Stephen Eilert]

On Thursday, March 22, 2012, Evan Hanson wrote:

> A few days ago I put together a buildpack that allows one to run Chicken
> apps on Heroku; figured I'd share it here in case someone else finds it
> useful.
>

Awesome! Thanks.


-- Stephen


-- 

-- Stephen

*"Kids these days.*
*Whatever happened to hard work?"*

   -- Joel Spolsky, The perils of javaschools
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] case vs. eq? - just curious ....

[Stephen Eilert]

On Sat, Mar 3, 2012 at 3:31 PM, Peter Bex  wrote:

> But the disadvantage is of course that it also means you can't use the
> power of these facilities when they are called for (see also the lack of
> general SLIME integration for Scheme).
>

Precisely!

Being able to "introspect" and patch code at runtime could lead to nifty
development tools indeed, even if they were only available on 'csi'.


-- Stephen

*"Kids these days.*
*Whatever happened to hard work?"*

   -- Joel Spolsky, The perils of javaschools
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] llvm patches integrated (was: Installing on Mac OS 10.7.3)

[Stephen Eilert]

On Sat, Feb 18, 2012 at 8:21 PM, Jim Ursetto  wrote:

> All LLVM patches are now integrated into stability 4.7.0.5-st and the
> stability tarball (http://wiki.call-cc.org/stability), as well as master.
>  So the dance below is no longer necessary.
>
> Additionally, these patches fix llvm-gcc and clang builds on Linux as well.
>
> Users are encouraged to test this out if interested.  At the least, it
> seems to speed up the build process, along with the chicken compiler.


Works beautifully! *Does happy Chicken dance*

I changed the homebrew formula and it worked right away. I could always
submit a pull request and point the formula to the stability branches,
instead of the latest release.



-- Stephen

*"Kids these days.*
*Whatever happened to hard work?"*

   -- Joel Spolsky, The perils of javaschools
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Installing on Mac OS 10.7.3

[Stephen Eilert]

On Tue, Feb 14, 2012 at 12:28 PM, Jim Ursetto  wrote:

> On Feb 14, 2012, at 9:26 AM, Jim Ursetto wrote:
>
> > This works with XCode 4.2 on Lion.  If this works without hanging,
> you're done.
> > If you have already upgraded to XCode 4.3...
>
> Oops.  I meant it works until XCode 4.2, and if you upgraded to XCode 4.2
> already (which you probably have) then you have to follow the other
> alternate instructions.  Even I am confused.
> Jim


So, in case one has upgraded to XCode 4.3 already and doesn't have a
chicken binary anymore...



-- Stephen

*"Kids these days.*
*Whatever happened to hard work?"*

   -- Joel Spolsky, The perils of javaschools
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] System Egg and recompilation

[Stephen Eilert]

Hello,

I've begun using the "system" egg in one of my projects and it's been very
hepful. However, every time the executable is started, files are
recompiled, even if they haven't changed. Let me clarify:

I have the following .system file:

(define-system common
  (compiled-scheme-file "common/point")
  (compiled-scheme-file "common/bufops")
  (compiled-scheme-file "common/buffers"))

(define-system front-end
  (compiled-scheme-file "front-ends/faces")
  (compiled-scheme-file "front-ends/widgets")
  (compiled-scheme-file "front-ends/cairo-renderer")
  (compiled-scheme-file "main"))

I load it like so:

(use system
 posix)

(load "grafitti.system")

(load-system common)
(load-system front-end)

When running, I get several lines of output like:

; front-end: file "front-ends/widgets" needs to be reloaded because it
hasn't been loaded yet
; compiling front-ends/widgets.scm ...
  /usr/local/bin/csc -s -S -O2 -d2 front-ends/widgets.scm -o
/tmp/temp6bb7.so

It compiles to the "tmp" directory, every time. Ideally, I'd like the
shared objects to stick around and only be recompiled if the files are
changed. "build-system" works, but then the files are ignored by
load-system (as per documentation).

Is this the expected behavior?



-- Stephen

*"Kids these days.*
*Whatever happened to hard work?"*

   -- Joel Spolsky, The perils of javaschools
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Chicken objc egg on OSX Lion

[Stephen Eilert]

On Sat, Nov 19, 2011 at 5:55 PM, Jim Ursetto  wrote:

>
> On Nov 19, 2011, at 11:01 AM, Achint Sandhu wrote:
>
> >   The cleanest option I have found so far is the objective-C
> extension for Chicken Scheme (http://wiki.call-cc.org/eggref/4/objc),
> which I'm having trouble installing on 10.7.
> >
> >   A quick google search reveals
> http://lists.gnu.org/archive/html/chicken-users/2010-12/msg00041.html and
> http://comments.gmane.org/gmane.lisp.scheme.chicken/12638 which seem to
> indicate that the objc extension isn't being actively developed and/or
> maintained.
>
> Correct, objc is not supported on 10.6 or higher, due to significant
> internal changes from Objective C 1.0 to 2.0 in that version.
>
>
Sorry for digging up an old thread but, what would those significant
internal changes be? Where would one have to begin in order to understand
the code?



-- Stephen

*"Kids these days.*
*Whatever happened to hard work?"*

   -- Joel Spolsky, The perils of javaschools
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] [ANN] Web and GUI related libraries

[Stephen Eilert]

On Fri, Sep 23, 2011 at 11:55 PM, Thomas Chust  wrote:

> Hello,
>
> I've been playing around with two small library projects related to
> web and GUI development:
>
>  *  http://www.chust.org/fossils/webkit
>
> A CHICKEN binding to WebKitGTK+ and JavaScriptCore. Runs a GTK+
> event loop in a CHICKEN thread, allows you to display HTML as a
> GUI and to interact with the DOM and other JavaScript objects as
> if they were Scheme values.
>

YEH! Thanks for that! It could lead to awesome stuff.


-- Stephen

*"Kids these days.*
*Whatever happened to hard work?*

   -- Joel Spolsky, The perils of javaschools"
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] Coops print-object, error handling and flaming koalas

[Stephen Eilert]

Today I hit a problem with some trivial code I wrote using Coops that I just
couldn't figure out. The relevant code is here:

http://paste.call-cc.org/paste?id=d09b2c1438a7f063c07cd089fb3e74c68d0b2804

Yeah, I forgot to add the "port" argument. In any case, Coops' error message
is misleading:

#'>>

There is a method alright, it's just crashing :)

Now, This is how coops handles the situation:

(define-record-printer (coops-instance obj out)
>   (handle-exceptions ex
>  (begin
>(display "#(default-print-method obj out)
>(display ">" out))
>  (print-object obj out) ) )


It will display the same error message regardless of the condition. So let's
modify it to see what it was:

(define-record-printer (coops-instance obj out)
>   (handle-exceptions ex
>  (begin
>(display ((condition-property-accessor 'exn
> 'message)))
>   ; (display "#(default-print-method obj out)
>(display ">" out))
>  (print-object obj out) ) )


The actual error is thus:  #
which is an (exn arity), in my code.

As pointed out by sjaaman, it should only catch the dispatch error. I could
create a patch to do that, but I am not confortable enough with coops' code
at this point and I am sure the error handling could be improved in ways I
can't even see yet..


Also, there are no flaming koalas.



-- Stephen

*"Kids these days.*
*Whatever happened to hard work?*

   -- Joel Spolsky, The perils of javaschools"
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] State of Clojure Survey

[Stephen Eilert]

http://cemerick.com/2011/07/11/results-of-the-2011-state-of-clojure-survey/

What about a "State of Chicken"? :)


--Stephen

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] ANN: The `str#' macro

[Stephen Eilert]

On Sat, Jun 25, 2011 at 2:59 PM, Kon Lovett  wrote:
> Hi,
>
> Just added `str#' to the moremacros egg. It behaves like #<# but for regular
> strings. Might be useful.
>
> (str# "(+ 1 2) = #{(+ 1 2)}")   => "(+ 1 2) = 3"        <= (conc "(+ 1 2) =
> " (+ 1 2))
>
> (str# "(+ 1 2) = #(+ 1 2)")     => "(+ 1 2) = 3"        <= (conc "(+ 1 2) =
> " (+ 1 2))
>
> (str# "#{23}###{45}")           => "23#45"              <= (conc 23 "#" 45)
>
> (Does not require data-structures to be imported even though conc is used.)
>
> Best Wishes,
> Kon

Fi fa fo fum... I smell the blood of Ruby...



--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] IUP Web

[Stephen Eilert]

On Sat, May 21, 2011 at 3:15 PM, Thomas Chust  wrote:
> 2011/5/20 Stephen Eilert :
>> [...]
>> The following link seems to indicate that there should be an IUP-WEB
>> egg. Henrietta doesn't know about it though.
>> [...]
>
> Hello Stephen,
>
> the iup-web library is part of the iup egg distribution. It is
> compiled and installed automatically together with the rest of the IUP
> bindings if the necessary backend libraries are available.
>
> Ciao,
> Thomas

Hey,

Found the problem: iup-web.scm is only available in trunk, not in the
latest tagged version..

Thanks again for the awesome egg.


--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] Chicken-IUP installer is down

[Stephen Eilert]

As the title says, http://www.kiatoa.com/cgi-bin/chicken-iup/home is down.

It says "The database schema on the server is out-of-date. Please ask
the administrator to run fossil rebuild."


--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] IUP Web

[Stephen Eilert]

On Sat, May 21, 2011 at 3:15 PM, Thomas Chust  wrote:
> 2011/5/20 Stephen Eilert :
>> [...]
>> The following link seems to indicate that there should be an IUP-WEB
>> egg. Henrietta doesn't know about it though.
>> [...]
>
> Hello Stephen,
>
> the iup-web library is part of the iup egg distribution. It is
> compiled and installed automatically together with the rest of the IUP
> bindings if the necessary backend libraries are available.

Alright.

I should be missing libraries then, because iup-web doesn't seem to get built.

How do I troubleshoot it? I can't find a single mention of the word
"web" in the sources.



--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] IUP Web

[Stephen Eilert]

Guys,

The following link seems to indicate that there should be an IUP-WEB
egg. Henrietta doesn't know about it though.

http://www.chust.org/fossils/iup/doc/trunk/api/web.wiki



--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] [wish list] chicken-install: show available eggs, upgrade all installed eggs?

[Stephen Eilert]

On Thu, May 5, 2011 at 7:06 AM, Felix
 wrote:
> Hello!
>
>> It would be good to be able to show available eggs when installing an egg, 
>> such
>> that user can grep and find wanted eggs quickly without having to browse at
>> http://wiki.call-cc.org/chicken-projects/egg- index-4.html.  Simply a text 
>> dump
>> of that html page would help much.
>
> That is possible, but would require a regularly updated "master" document 
> somewhere
> on our server.

Henrietta already provides a list of eggs to chicken-install. I
suppose that could be used, if we don't care about showing egg
descriptions in such a list.

>
>>
>> The other feature is being able to upgrade all installed eggs after, for
>> instance, upgrading chicken.  Then i don't have to reinstall each missing 
>> one by
>> one, desperately.
>
> That has been requested repeatedly in the past, but I'm
> sceptical. Bulk updates like that make it extremely easy to break
> everything, unless you have a very rigid control over the stability of
> the currently available extensions.  The egg repository is actually
> pretty good in that regard, but still, broken eggs and broken
> dependencies slip in from time to time. We are quick to fix those, but
> something like a bulk update could easily result in broken
> installations.
>
> For example, I may have several applications that use one or the other
> installed egg. Those eggs may be out of date, but I'm more interested
> in having my system running, so when I install new extensions,
> "chicken-install" will warn me when an egg requires higher versions
> and I have the choice to think twice about whether I want to do that
> or not.

But only if you already know which versions you are supposed to be
using. For deployed code, I guess you could take the list from a
running server, manually. For code sitting in a repository, it doesn't
work like that. Even when you do know the versions, it could get
tedious.

However, you've already provided the solution for that, your 'overrides' :)


--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Difficulty installing Hyde egg

[Stephen Eilert]

On Sun, Apr 3, 2011 at 3:06 PM, John Magolske  wrote:
> Hi all,
>
> I'd like to to install the Hyde egg into a location in my home
> directory:
>
>  % chicken-install -v
>  4.6.0
>
>  % echo $CHICKEN_REPOSITORY
>  /home/john/.chicken/lib/chicken/5
>
>  % echo $CHICKEN_INCLUDE_PATH
>  /home/john/.chicken/lib/chicken/5
>
>  % chicken-install -p ~/.chicken/lib/chicken/5 hyde
>
> But the install gets stuck here:
>
>  [...]
>  Warning: extension `defstruct' is currently not installed
>  Syntax error (import): cannot import from undefined module
>
>    defstruct
>
>    Expansion history:
>
>          (import matchable)
>          (import scheme chicken)
>          (##core#undefined)
>          (##core#undefined)
>          (##core#begin (##core#begin (##sys#require (quote defstruct))
>                  (import defstruct)) (##core#begin (##c..
>          (##core#begin (##sys#require (quote defstruct))
>                  (import defstruct))
>          (##sys#require (quote defstruct))
>          (quote defstruct)
>          (##core#quote defstruct)
>          (import defstruct)    <--
>
>  Error: shell command terminated with non-zero exit status 17920:
>  /usr/bin/chicken uri-generic.scm -output-file uri-generic.c -
>  dynamic -feature chicken-compile-shared -feature compiling-extension
>  -setup-mode -optimize-level 2 -emit-import-library uri- generic
>
>  Error: shell command failed with nonzero exit status 256:
>
>    /usr/bin/csc -feature compiling-extension -setup-mode
>      -s -O2 uri-generic.scm -j uri-generic
>
>  Error: shell command terminated with nonzero exit code 17920
>  "/usr/bin/csi -bnq -setup-mode -e \"(require-library setup-api)\" -e 
> \"(import s...
>
> I tried installing defstruct first:
>
>  % chicken-install -p ~/.chicken/lib/chicken/5 defstruct
>
> Which installed without error. But I still get the above "`defstruct'
> is currently not installed" error when trying to install Hyde again.
> Am I overlooking something? I'm using Debian Sid, and have installed
> Chicken using aptitude.

Are you able to install it without using the custom prefix?


--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Creating Windows GUI App

[Stephen Eilert]

On Thu, Mar 31, 2011 at 1:46 PM, Thomas Chust  wrote:
> 2011/3/31 Steve Graham 
>> Can someone point me to some info on this?
>
> Hello Steve,
>
> there is compiler support for executables marked as GUI applications
> through the -gui command line option. But to actually create a GUI,
> you will have to use one of the eggs providing bindings for user
> interface toolkits [1]. All the Tk and Qt based ones should, in
> principle, work under Windows. The IUP binding is also known to work
> under Windows.
>
>> Also does Chicken Scheme have a method for accessing databases?
>
> Yes, check the eggs providing database functionality [2]. However,
> there is currently no database-independent layer like Perl's DBI
> module that provides a uniform API for all other relational database
> drivers.

Oh, that's been one of my pet peeves for a long time now. The closest
we have is awful's $db procedure.

I've toyed with the idea, but I am afraid I'm not knowledgeable enough
about all RDBMS to come up with a decent API. Any suggestions?


-- Stephen

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] ANN: Test version of new egg release system available

[Stephen Eilert]

On Thu, Mar 31, 2011 at 11:34 AM, John Cowan  wrote:
> Peter Bex scripsit:
>
>> We're actually still looking for a good way to handle this.  Currently
>> egg authors must contact one of the "usual suspects" to have them update
>> or add a location.
>
> I think it's a Good Thing to have some human gatekeeping here.  We really
> don't want the egg repository filled with random eggs with misleading,
> obscene, or spammy names.

Perhaps, even though I find that very unlikely.

Human interaction shouldn't be more complicated than pushing a button
somewhere to 'approve' said egg, tho. Everything else should be
automated.


-- Stephen

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Re: dbus:send bug

[Stephen Eilert]

On Wed, Mar 16, 2011 at 5:46 PM, Peter Bex  wrote:
> On Wed, Mar 16, 2011 at 04:39:46PM -0400, John Cowan wrote:
>> Egg documentation should not be documentation of the code (implementation)
>> of the egg, but of its interface.
>
> Thank you for that.  You made my point more concisely than I could
> ever hope to.

Very well. I'll stop the bikeshedding.

For now. Mwahahahah.


--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Re: dbus:send bug

[Stephen Eilert]

On Wed, Mar 16, 2011 at 3:34 PM, Peter Bex  wrote:
> On Wed, Mar 16, 2011 at 02:58:59PM -0300, Stephen Eilert wrote:
>> > Documentation for eggs is usually manually written.  As far as I know,
>> > nobody uses automatic extraction of comments from code.
>>
>> And that's a shame.
>
> Why?
>
> Almost all the "extracted" documentation I've seen is of shitty quality;
> people tend to use automatic extraction of docs as an excuse not to
> write proper documentation.

As opposed to not writing it at all, or having it get out of sync with
the code, as they live in different places. Also, it is trivial to
extract documentation for, say, an older egg version. Which is in sync
with the code, by default.

When you have documentation in the code, it goes wherever that code goes.

>
> Also, writing documentation by hand forces one to think about writing
> it in a way that it can be read from beginning to end and have it make
> sense.

But that's usually done after the code has been written, as an afterthought.

> Having documentation on a wiki means people can add notes about and
> rewrite sections they found difficult or hard to understand, thereby
> increasing overall quality.

Notes can be added no matter how the documentation is generated. As
for rewriting sections, I agree with you - it is easier in a wiki. It
would be helpful to know how often that happens in practice, though.

One can make the argument that it would be *easier* to document the
code because you are looking at it, it is sitting right next to the
docs. If you are reading it in the source you can even spot the fact
that, say, a function's arguments are documented wrong, because you
can see it right there.


> Finally, when the inline documentation *is* done really well, you end
> up with a lot of documentation getting in the way when you're trying to
> read the code.

That is also true. See, for instance, ActiveRecord. It has benefits
too - you can see the documentation right next to the section you are
editing or trying to understand and breaks up code sections visually
(when done well).

I have stopped complaining about the lack of docstrings when
chicken-doc (and chickadee) was created. It is not an ideal solution
(from my point of view), but it mostly solves the problem of
retrieving the documentation for chicken and eggs in the repository.

However, I still think that it could be useful. If not for Core and
Eggs, then perhaps for our own Scheme projects. Maybe some hack using
Hyde?


--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Re: dbus:send bug

[Stephen Eilert]

On Wed, Mar 16, 2011 at 2:03 PM, Mario Domenech Goulart
 wrote:
> Hi John,
>
> On Wed, 16 Mar 2011 12:55:54 -0400 John J Foerch  
> wrote:
>
>> Christian Kellermann  writes:
>>>
 This is misleading.  It should say "send a signal" instead of "message".
 The second clause is also misleading, because there is simply no
 response to wait for.

 Then the examples just need to be fixed up to use dbus:call instead of
 dbus:send.  The second example uses dbus:send-and-await-reply, which
 isn't even part of the api.  It seems to have a different call form from
 dbus:call, so we would have to examine that more closely and figure out
 what the intent was.
>>>
>>> First of all, thanks for your detailed report!  As you are the first
>>> user of this egg after a long time I would suspect some bitrot.
>>> Please feel free to change the wiki page as you see fit and maybe
>>> send patches for the egg to the author, maybe cc'ed to this list.
>>> I hope you are not put off by all the dust that has set on this
>>> extension. Let's make it better!
>>
>> Okay, great.  For some reason I hadn't noticed that I could edit that
>> page.  I thought the egg pages were auto-generated from inline comments
>> in the eggs themselves (or something).  So I will work on cleaning that
>> up and contact the author about the couple of bugs I've found in the
>> code itself.
>
> Excellent.
>
> Documentation for eggs is usually manually written.  As far as I know,
> nobody uses automatic extraction of comments from code.

And that's a shame.


--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] Fwd: [lisp-game-dev] industry journal article on lisp in games

[Stephen Eilert]

Not related to Chicken specifically, but I found it to be an interesting read.


--Stephen

Sent from my Emacs



-- Forwarded message --
From: David O'Toole 
Date: Mon, Mar 14, 2011 at 1:55 AM
Subject: [lisp-game-dev] industry journal article on lisp in games
To: lisp-game-dev 


I found this really interesting industry article on Lisp in game
development (link below) Apparently this is being republished from a
print journal, so I'm not sure if anyone here has read it before. I've
read a chunk of the article and it's fascinating to finally see more
details on the legendary GOOL (predecessor of GOAL) used in some very
popular Playstation 2 games.

http://all-things-andy-gavin.com/2011/03/12/making-crash-bandicoot-gool-part-9/

Let's put more of our knowledge on the mailing list so that Google
(and people who don't use IRC) can see it :) I'll post thoughts after
I finish reading.

___
lisp-game-dev mailing list
lisp-game-...@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/lisp-game-dev

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] raw packet interface

[Stephen Eilert]

On Mar 9, 2011, at 10:29 PM, Nicolas Pelletier wrote:

> Hello Chickenistas,
> 
> As part of testing a network appliance (router/firewall etc...), I'd
> like to be able to read and write arbitrary data to the network. So
> I'm wondering if somebody has already some tools to interface to
> low-level networking services, such as BPF, libpcap... I am trying to
> find error cases in the handling of incoming packets in the appliance;
> I do not need throughput performance nor very precise timings. I am
> running under FreeBSD 8.1. I'd be grateful for any advice.

I am not aware anyone doing raw packet access in Scheme. 

Do you think that bindings for libpcap would be enough for your purposes?


-- Stephen

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Mac OS X Installation

[Stephen Eilert]

2011/3/3 Andrew Pennebaker :
> At http://wiki.call-cc.org/platforms#macports, users are instructed to
> install Chicken using MacPorts, then a caveat about a missing dylib file,
> then instructions for installing Chicken using Homebrew.
> Since MacPorts Chicken is broken, why not list the Homebrew option first.
> New schemers (myself included) will do the first option listed, nevermind
> that it's the more problematic one.

Probably just because Homebrew is newer and not many people use it
(compared to MacPorts).

But the homebrew install works fine at the moment (it installs 4.6.0).
I have even added an option to install Chicken from Git head - not
sure it made upstream. It will require a previous Chicken install, as
it is not aware of any bootstrapping requirements.



--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] coops

[Stephen Eilert]

On Wed, Feb 2, 2011 at 5:29 PM, Felix
 wrote:
> From: Stephen Eilert 
> Subject: Re: [Chicken-users] coops
> Date: Wed, 2 Feb 2011 15:32:33 -0300
>
>> On Wed, Feb 2, 2011 at 2:24 PM,   wrote:
>>> Sometimes the simplest solution are the hardest to see. I do not have to use
>>> coops-primitive-objects, I can define my own hierarchie of primitive
>>> objects.
>>
>> That is my experience as well. Every time I import
>> coops-primitive-objects, I end up removing it some time later.
>
> After all the work I put into it? My heart bleeds ...

I've yet to define generic methods on, say, continuations or threads.
I assume coops-primitive-objects will be much more useful for those.
The issue is not with coops-primitive-objects. Instead, as a program
progresses it is sometimes useful to redefine old functions and have
them accept more 'specialized' objects.

Maybe that's just me.


--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] coops

[Stephen Eilert]

On Wed, Feb 2, 2011 at 2:24 PM,   wrote:
> Sometimes the simplest solution are the hardest to see. I do not have to use
> coops-primitive-objects, I can define my own hierarchie of primitive
> objects.

That is my experience as well. Every time I import
coops-primitive-objects, I end up removing it some time later.


--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] readline egg (OS X 10.6.6 / Chicken 4.6.0)

[Stephen Eilert]

On Wed, Jan 26, 2011 at 8:59 AM, David Dreisigmeyer
 wrote:
> This version of Chicken is not from Macports, but readline is.  I had
> tried various CSC_OPTIONS in my .profile, e.g.:
>
> export CSC_OPTIONS="-L/opt/local/lib -I/opt/local/include"
> export CSC_OPTIONS="-L/opt/local/lib -I/opt/local/include/readline"
>
> and also using the -rpath flag after your suggestion.  None of these
> worked though, and I always received the error:

What about setting LIBRARY_PATH:

export LIBRARY_PATH=/opt/local/lib

I'm using Homebrew instead of macports nowadays, but I had to install
readline yesterday and setting LIBRARY_PATH and CSC_OPTIONS did the
trick (after symlinking to usr/local with 'brew link readline').


--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] The following code causes a segfault in the chicken interpreter (forwarded)

[Stephen Eilert]

2011/1/17 Mario Domenech Goulart :
>
>
> --
> http://parenteses.org/mario
>
>
> -- Forwarded message --
> From: Tom Ostojich 
> To: mario.goul...@gmail.com
> Date: Mon, 17 Jan 2011 13:13:38 -0600
> Subject: The following code causes a segfault in the chicken interpreter
> Hey,
>
> Using csi version 4.2.0 on GNU/Linux (Ubuntu 10.04) built for x86
> causes a segfault when the following code is evaluated:
>
> (define-syntax ∫
>        (syntax rules ()
>                ((∫ x ...) '(x ...
>
> (∫ x ^2 + x + 1 dx)
>
> Considering that segfaults are fairly serious, I figured that it I
> should let you know.
>
> Thanks for reading,
>
> Tom
>
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/chicken-users
>
>


Can't reproduce that here.

Chicken 4.6.0, ubuntu 10.04


--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Re: seg fault

[Stephen Eilert]

On Tue, Nov 30, 2010 at 11:51 AM, David Dreisigmeyer
 wrote:
> You can do this to default to 64-bit, versus 32-bit:
>
> http://www.overclock.net/mac/564147-how-enable-64-bit-default-os.html

Does it help with this specific issue?

Even with a 32-bit kernel (and extensions), OSX will run 64bit
applications just fine.

Furthermore, some machines cannot enable the 64-bit kernel (my White
Macbook doesn't seem to be able to, for instance).


--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Memoizing a procedure

[Stephen Eilert]

On Mon, Nov 29, 2010 at 10:29 AM, Jörg F. Wittenberger
 wrote:
> Am Montag, den 29.11.2010, 13:53 +0100 schrieb Jörg F. Wittenberger:
>> Hi Hugo,
>>
>> Am Sonntag, den 28.11.2010, 17:27 +0100 schrieb Peter Bex:
>> > On Sun, Nov 28, 2010 at 12:53:53PM -0300, Hugo Arregui wrote:
>> > > Hi guys,
>> (define (make-memoized proc)
>>   (let ((memo (make-hash-table))
>>         (missing (list 'missing)))
>>     (lambda args
>>       (let ((result (hash-table-ref memo args
>>                                   (lambda ()
>>                                     (let ((x (cons missing (make-mutex
>>                                       (hash-table-set! memo args x)
>>                                       x)
>>         (when (and (pair? result) (eq? (car result) missing))
>>           (let ((mux (cdr result)))
>>             (mutex-lock! mux)
>>           (when (and (pair? result) (eq? (car result) missing))
>>               (set! result (apply proc args))
>>             (hash-table-set! memo args result))
>>             (mutex-unlock! mux)))
>>         result
>>
>> Note, however that this will not work, if your memoized procedure
>> terminates by exception!
>
> Note also, that hash tables in chicken are not thread safe, hence you'd
> need some more locking anyway.  Left as an exercise.
>
> Be warned however, that you don't want to grow that code too much.
> "Recently" - that is I'm still kind of screwing with it - wrote some
> code, which handles such cases, plus some optional features like
> timeout's for the result being taken to be valid (which comes in handy,
> when you want to memoize procedures, which return temporary valid values
> (e.g., network connections), cache-cleanup's.  It can easily outgrow the
> scope of an educational exercise.

So it is not only "memoization", but a caching system. I was going to
write something similar, to cache webservice responses.


--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] upgrading to 4.6.0 in Arch

[Stephen Eilert]

On Fri, Nov 12, 2010 at 6:09 AM, Felix
 wrote:
> From: Hugo Arregui 
> Subject: [Chicken-users] upgrading to 4.6.0 in Arch
> Date: Thu, 11 Nov 2010 11:14:10 -0300
>
>> Hi everyone,
>>
>> I have a few doubts after the upgrade:
>>
>> - Which is the right procedure to upgrade eggs?
>
> There is no standard procedure for this. Just upgrade eggs as you need
> them, keep the old ones in case they are working or simply uninstall
> and reinstall everything you need.  Automatic upgrading has turned out
> to be too fragile and complex and fresh installation usually works
> smoothly enough.
>

On that note, perhaps something to show 'outdated' eggs could be helpful.


--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Trouble with FFI and 64 bit machines

[Stephen Eilert]

On Fri, Oct 8, 2010 at 3:58 PM, Peter Bex  wrote:
>
> I'm not sure if that's the problem with your egg, but this results in a
> compiler warning because there's no prototype for that function, so
> C assumes the return value's type is 'int', which is indeed a different
> size than void * on x86_64.
>
> Adding (foreign-declare "void *mkd_in(void *, int);") in front of that
> code causes it to compile without warnings.
>
> Perhaps you should figure out whether the header file is being included
> properly.  Maybe you can temporarily put a "#error hi" just before the
> function's prototype in the header file, so you can see if it's not
> skipping the prototype due to a #ifdef or something equally silly.

The reason was something even more silly: I was not including the
header file at all. Turning on -Wall reveals that yes, the prototype
was missing. GCC is appeased now.

I'll test it on OSX later, but it is likely that this will fix the problem.

Thanks,


--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] Trouble with FFI and 64 bit machines

[Stephen Eilert]

Hi guys,

As some of you might be aware, I am creating bindings for the Discount
(http://www.pell.portland.or.us/~orc/Code/discount/) library. However,
I have run into a problem.

When testing on my OSX (Snow Leopard) machine with a 64 bit chicken, I
get a segfault. After some debugging (and Ventonegro's help), I've
narrowed it down to the following definition:

(define mkd_in
  (foreign-lambda c-pointer mkd_in c-pointer int))

  The function being bound is "MMIOT* mkd_in(FILE *f, int flags)"
(where MMIOT is defined as void by the header file), which returns a
pointer that is fed to the 'markdown' function for processing and
blows up the first time it is dereferenced.


I get the following compilation warning, which is likely the source of
the corrupt pointer:

csc -c testcase.scm
testcase.c: In function 'stub3':
testcase.c:31: warning: cast to pointer from integer of different size

Even though I get the same warnings under Ubuntu 64, it runs fine.

To reproduce the warning:

Just create a file containing the above foreign-lambda and compile it
with csc -c.

The full code is in github: git://github.com/spedrosa/Discount.git
(requires libmarkdown)

I'll do more OSX tests later today, but assistance would be helpful :)


--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Scheme code to be read

[Stephen Eilert]

On Wed, Aug 18, 2010 at 12:02 PM, Christiano F. Haesbaert
 wrote:
> Hi there,
>
> I'm in the point that I can code most stuff in scheme, but I do it
> poorly mainly cause I'm not familiar with the basic SRFIs, the
> language itself and good scheme practices, read: I do not know the
> scheme coding *culture*.
>
> Far too many times I ended up coding something which already existed,
> or doing something really stupid (that worked).
>
> Can you guys point me to some good scheme code ?
> I believe this is the only way to learn.
>
> Thanks.

>From time to time I download egg sources and study them. It has proven
very instructive.


--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] sql-de-lite integrated SQLite3 library

[Stephen Eilert]

On Thu, Aug 12, 2010 at 2:21 AM, Jim Ursetto  wrote:
> Hi there.
>
> SQLite3 is a great, lightweight database, but I have hesitated to use
> it in Chicken applications because it's not guaranteed to be installed
> or recent enough on a user's machine -- especially if they're on
> Windows or OS X.  Installing it can be an annoying extra step for your
> users.
>
> To that end, I've updated the sql-de-lite egg to include an integrated
> SQLite3 library, currently 3.7.0.1.  At installation time, the egg
> will auto-detect whether your system library is present and recent
> enough.  If so, it links against your system library; if not, it links
> against the built-in library.  It's also possible to override the
> auto-detection if desired.
>
> The goal is to allow you to just depend on sql-de-lite in your
> application and not worry about whether the library is installed or
> too old.  SQLite3 is a great replacement for ad-hoc file formats and,
> even if you are not a fan of SQL, the underlying database tech is
> top-notch.
>
> Integrated build has been tested on OS X 10.5, mingw32, and Ubuntu
> 10.04.  Just run `chicken-install -test sql-de-lite` if you would like
> to test it out, and please report back any bugs or successes.
>
> For more details, see http://3e8.org/chickadee/sql-de-lite#sec:Installation.
>

Hey, that's awesome :)


--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Curious: why the name "Chicken Scheme"?

[Stephen Eilert]

2010/8/11 Emeka :
> And what about Egg too?
>

hmmm... Chickens are oviparous? :)


--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] (apparently) solved; patch attached -- was: clueless about memory consumption.

[Stephen Eilert]

2010/7/26 Jörg F. Wittenberger :
> Struggling with git I apparently and unintentionally committed some
> changes locally.  No idea how to undo that.

git reset  --hard

should "undo" the changes.

In any case, how are you generating the diffs? with git diff or git
format-patch?



--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Exporting proc and macro that references it?

[Stephen Eilert]

Try

(define-for-syntax (register) #f)


--Stephen

Sent from my Emacs



On Mon, Jul 5, 2010 at 10:45 AM, Alejandro Forero Cuervo
 wrote:
> Oh, BTW, the meta file has a "needs" entry that you'll probably want
> to remove while testing this.
>
> Alejo.
> http://azul.freaks-unidos.net/
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/chicken-users
>

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] Chicken-install and http_proxy

[Stephen Eilert]

Hi guys,

It is standard for Linux to configure HTTP proxies using the http_proxy 
environment variable, as I had to discover painfully at work. Graphical tools 
(like Gnome's proxy settings) will even set it automatically.

The -proxy option in chicken-install is handy. However, by recognizing the env 
variable, chicken-install is able to use the system proxy automatically.

So, attached is a proposed patch. Some possible improvements:

* Add support for proxy authentication. The proxy at work actually requires 
this, but I have setup a local proxy to forward the requests, so that apps that 
don't support it will work. Or, at least, it should complain if a 
username/password combination is detected (like 
http://user:passw...@host:port";). 

Comments?


-- Stephen

Sent from my Emacs





0001-Added-code-to-recognize-the-http_proxy-environment-v.patch
Description: Binary data
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] On eggs and their licensing

[Stephen Eilert]

On Wed, Jun 2, 2010 at 11:56 AM, Peter Bex  wrote:
> On Wed, Jun 02, 2010 at 11:43:43AM -0300, Stephen Eilert wrote:
>> SRFI I have no idea. Ditto about the TK egg and the Bremer License,
>> the page didn't load for me here at work.
>
> The TK eggs and Bremer license were topic of a discussion a couple
> years back:
>
> http://lists.nongnu.org/archive/html/chicken-users/2008-02/msg00565.html
>
> Turned out that Bremer license is equivalent to BSD, but without the
> disclaimer which apparently makes the license void under German law.
> I find it hard to believe that one clause can void an entire license
> but apparently that's how it is.
>
> Unfortunately, I was never able to contact Wolf-Dieter Busch to ask
> him about this and a possible license switch to BSD.  You're welcome to
> give it another try, though!

If this makes the license void under the German law I can understand
the reasoning.

I'll give it another try in any case.

Did anyone contact the FSF about that license? I can't find it in the thread.

-- Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] On eggs and their licensing

[Stephen Eilert]

Hi, Chickeners.

As I have some code that I would like to contribute back to Chicken,
in the form of eggs, I have started to look into the licensing issue.
I've asked that on #chicken, and the response was that I should choose
my own license.

Sure enough, the eggs page show *a mess*. We have all sorts of
licensing, including Public Domain, BSD, MIT, LGPL, GPL-2 and GPL-3.
This is the egg breakdown, according to the eggs page:

BSD: 168 eggs
Artistic: 3 eggs
Bremer License: 1 egg
Free Use(?): 1 egg
GPL-2: 5 eggs
GPL-3: 47 eggs
LGPL(no version specified): 6 eggs
LGPL-1: 2 eggs
LGPL-2: 1 egg
LGPL-2.1: 9 eggs
LGPL-3: 2 eggs
MIT: 11 eggs
Public domain: 25 eggs
SRFI: 5 eggs
Unknown(this shouldn't even exist): 4 eggs
XEROX: 1 egg

Henrietta lists more eggs, but they probably aren't visible.

Since eggs are just a chicken-install away, it is non-trivial to
determine the legality of a project that uses several of these. And,
as a lot of Chicken development nowadays is being done on web servers
(and we haven't got a single AGPL egg on that list) we can get away
with it for now.

This will indubitably generate a flame fest about which license is
best, but this is not the intention. Rather, it is to figure out a
policy for egg licensing and let authors make informed decisions.

Sjamaan suggested that eggs should preferably follow Chicken's
license, and I agree with that. Some deviation is unavoidable,
specially when eggs bind to external libraries or when they are
ported(hence the XEROX license, for instance). Ideally those should be
an exception and chicken-install (or even chicken itself) should throw
a warning.

To reiterate, this is not to say that one should be forced to choose a
license. Rather, I see two fronts:

1- Sort out the existing eggs
   1.1 - Contact the 'Unknown license' egg authors to agree on a
license for the existing code. There are just a few of these,
thankfully.
   1.2 - See if it is possible to 'Upgrade' the license in some eggs,
to reduce version complexity (LGPL guys, I'm looking at you)
   1.3 - Figure out which licenses are compatible between each other
and post this information in the Wiki. Preferably with comments about
suitability for closed-source projects. I have seen some general
information, but assistance from FSF might be required.

2- New eggs
   2.1 - Write licensing guidelines for new eggs, providing a list of
'recommended' licenses and an explanation for each. The list is of
course just a recommendation, but it would allow someone who has yet
to decide to make an informed decision.
   This seems to be a useful starting point:
http://www.dina.dk/~abraham/rants/license.html

   2.2 - Only publish eggs when the license is provided. It's fine for
them to sit in the repository while in progress, of course. I do know
if it is currently being done, but the existence of 'unknown license'
eggs says it is not.
   2.3 - chicken-install and chicken-status should provide licensing
information.
   2.4 - If they are using a standard license with exceptions, those
should be listed explicitely.

As an example of how complicated things are, this is from
http://www.gnu.org/licenses/license-list.html

LGPL 2.1: Compatible with GPL2 and GPL3.
LGPL 3: Compatible with GPL3, but not with GPL2.
GPL 2: May or may not be compatible with GPL 3, has its own FAQ and
gave me a headache.
Artistic License is compatible with GPL. What about LGPL? Doesn't say,
we have to check. HOWEVER, it is not even free software if the version
is 1.0.
MIT can be used to refer to the X11 License, but the page states that
MIT has used several licenses. We are probably using it to mean the
X11 one, but this is the kind of ambiguity lawyers thrive on.
SRFI I have no idea. Ditto about the TK egg and the Bremer License,
the page didn't load for me here at work.

I haven't seen dual-license eggs, but this is also possible.

Again, the idea is not to restrict authors. Its their code and they
can release it under the Infernal License - 3 that requires virgin
sacrifices. It is fine. But, if virgin sacrifices are not actually
required, maybe a BSD would suffice, making integration easier.

Comments are most welcome.


--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Implementing a remote REPL, can't see definitions

[Stephen Eilert]

Took me a few days to figure out this one.

Turns out that my program had (declare (block)) somewhere in it.


-- Stephen

Sent from my Emacs


On Mon, May 24, 2010 at 1:37 AM, Nicolas Pelletier
 wrote:
> Hello,
>
> On Sun, May 23, 2010 at 5:12 AM, Stephen Eilert  wrote:
>>
>> However, I cannot evaluate any definitions from the rest of the
>> program. It seems that I can create new ones, though.
>
> Are you saying that the bindings established by the rest of the
> program are not seen by eval ? If so, are you aware of the following
> construct (taken from
> http://community.schemewiki.org/?scheme-faq-misc#sicp) ?
>
> ((eval `(begin (define ,name #f)
>                (lambda (val) (set! ,name val)))
>        (interaction-environment))
>  value)
>
> Piping the needed values through lambda as in the above will let you
> control which definitions can be used, and might be enough for what
> you are trying to achieve.
>
>> I am not passing any other arguments to eval, so I suppose it is using
>> (interaction-environment).
>
> Correct. This means that a new interaction environment will be
> generated each time eval is called.
>
> Hope this helps,
>
> --
> Nicolas
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/chicken-users
>

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] define-macro in chicken 4?

[Stephen Eilert]

On Sun, May 23, 2010 at 4:44 PM, Alejandro Forero Cuervo
 wrote:

> Alejo, seriously wishing he had picked Python, Perl or Java, rather
> than Chicken, 5 years ago.
> http://azul.freaks-unidos.net/

Really?

Perl
http://www.codesimplicity.com/post/when-is-backwards-compatibility-not-worth-it/

Python
* Haven't really checked the individual changelogs dating back 5+
years. Probably best of the bunch here (with from future import
). And yet it does eventually break backwards compatibility.

http://arstechnica.com/open-source/news/2008/12/python-3-0-sheds-backwards-compatibility.ars

Java
* Generally compatible, except for the changes listed, of course. And
you cannot use mix and match new and old code.

http://java.sun.com/j2se/1.5.0/compatibility.html



--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] Implementing a remote REPL, can't see definitions

[Stephen Eilert]

Hello,

I am trying to implement a remote REPL under the iPhone simulator.
After a few false starts (regarding threads and callbacks) I now have
a functional REPL talking to a network socket. So far so good.

However, I cannot evaluate any definitions from the rest of the
program. It seems that I can create new ones, though.

I am not passing any other arguments to eval, so I suppose it is using
(interaction-environment).

How should I proceed? I've looked at CSI's repl, but there's a lot
there I can't understand.

Thanks for any insights.


--Stephen

Sent from my Emacs

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] Fwd: [gambit-list] Quantz/Steam promotion

[Stephen Eilert]

Thought it would be interesting to share with the Chicken people :)

--Stephen

programmer, n:
A red eyed, mumbling mammal capable of conversing with
inanimate monsters.


-- Forwarded message --
From: Marc Feeley 
Date: Thu, May 13, 2010 at 11:26 AM
Subject: [gambit-list] Quantz/Steam promotion
To: Gambit List , Montreal Scheme/Lisp
User Group 


I just noticed that Steam (a video game client/installer) is now
available for Mac, and for the occasion they have a special promotion
on Quantz, a game written mostly in Scheme with Gambit.  Quantz is
only $3, which is 70% off the normal price.  Another goodie is Portal,
a game of logic and physics, which is FREE until May 24th (note: it is
a 3.8GB download!).

Have fun!

Marc

___
Gambit-list mailing list
gambit-l...@iro.umontreal.ca
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

chicken-install commands (WAS: Re: [Chicken-users] Chicken on Windows (MinGW))

[Stephen Eilert]

On Thu, May 13, 2010 at 7:31 AM, Mario Domenech Goulart
 wrote:
> Hi Arthur!
>
> On Wed, 12 May 2010 17:39:26 -0300 Arthur Maciel  
> wrote:
>
>> I tried compiling it with MinGW and worked charmingly.
>>
>> I'm facing problems installing awful egg, as it complains that required 
>> version
>> of 'uri-generic' is older than 2. It says to run 'chicken-install
>> uri-generic:2', but no package is found.
>
> That's awful. :-) Strangely enough, awful doesn't directly depend on
> uri-generic.  Maybe it's uri-common which requires uri-generic >= 2.
>
> uri-common is required by intarweb and spiffy, and both are required by
> awful.  In fact there's no version "2", but there's "2.something".
> Maybe the message presented by chicken-install is misleading.
>
> You can try to update uri-generic. You just need to run
>
>    $ chicken-install uri-generic
>
> This command will pick the latest uri-generic version.

This is something I've meant to ask for a while now but forgot
completely. I think chicken-install would benefit from a few extra
commands. Some suggestions:

-update-all: this would update all installed eggs to their newest versions.

-outdated: Instead of blindly updating, you'd be able to check which
eggs are out-of-date

-list [name]: This would query the eggs available, preferably with a
quick summary (similar to the current eggs page). The optional name
argument would allow a filter.

-stale: Got the idea from rubygems. It would basically list the local
eggs with their last atime. Might be helpful for when we reach a
thousand gems ;)

I don't know if we need to change the server to support new commands.
I had already proposed a "list" command a while ago, but I don't
remember what the agreement was. Anyway, I am willing to implement
some of these, time permitting. Assuming you guys like the suggestions
:)


--Stephen

programmer, n:
A red eyed, mumbling mammal capable of conversing with
inanimate monsters.

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Interfacing to Non-C Languages

[Stephen Eilert]

On Wed, Apr 7, 2010 at 5:47 PM, Karl Winterling  wrote:
> Hi,
>
> I sort of wanted to know if anyone uses Chicken with systems languages
> other than C and C++, like, say, FreeBasic. It might be neat to have
> an egg for gfxlib.
>
> ---Karl
>
>

How would this interface be accomplished?


--Stephen

programmer, n:
A red eyed, mumbling mammal capable of conversing with
inanimate monsters.


___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] There are (module)s and there are (declare (unit s))...

[Stephen Eilert]

Now all that's missing are recipes on how to use these more effectively :)

Do not forget that you can (include) other files as well.

So far, I am using a combination of modules and includes.


--Stephen

programmer, n:
   A red eyed, mumbling mammal capable of conversing with inanimate
monsters.


On Thu, Dec 10, 2009 at 3:04 PM, Will M. Farr  wrote:

> Christian,
>
> On Dec 10, 2009, at 11:33 AM, Christian Kellermann wrote:
>
> > one thing that keeps bugging me repeatedly is the concept of a unit
> > as opposed to a module in chicken scheme. Could someone of the fine
> > people on this list point me to some hints in the docs or explain
> > here why there are those two separate things and what the differences
> > are?
>
> I was once puzzled by this, too, but I think I have figured it out now.
>  The other experts on this list can correct me if I make a mistake.
>
> The short summary: modules work on syntax, controlling the mapping between
> symbols and bindings at top-level.  Units work at runtime, ensuring that
> code is initialized and top-level statements are executed in the correct
> order.  Here's the long explanation:
>
> * modules: a syntactic construct that associates names (symbols) with
> bindings.  In Chicken, all bindings are top-level; a module lets you access
> those top-level bindings with different names (or even
> hide---effectively---some bindings because there is no name existing inside
> the module that refers to them).  Purely syntax.  Modules are very important
> for macros, because free symbols in the output of a hygenic macro should
> refer to bindings according to the mapping in place *when the macro was
> defined*, not the binding in place when the macro is used.
>
> * units: a way to designate some code as intended to be included in a
> larger library or program.  The issue that units try to solve is that, in
> general, top-level forms in Scheme have side-effects.  Consider:
>
> (define (foo x) (+ x 1))
>
> When this is "executed", the global namespace is extended with a binding
> for 'foo that refers to a function of a single argument that adds one to the
> argument.  This behind-the-scenes stuff must happen before any code runs
> that uses foo, or things break.  Units help ensure this.  The
>
> (declare (unit foo))
>
> declaration states that the code in this file is designated by the name
> foo.  The
>
> (declare (uses foo))
>
> declaration says "the following code uses definitions from foo", and
> ensures that all the behind-the-scenes stuff that needs to happen in the foo
> unit happens before executing any statements in the current file.
>
> In other words, units are a way of managing separate compilation of code.
>  Put some code into a unit and compile it.  Then "using" it in another bit
> of code will make sure that the code in the unit runs before any code in the
> "using" file (including all the behind-the-scenes stuff that needs to happen
> to initialize the bindings in the unit, etc).
>
> Does this help explain the difference?
>
> Will
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/chicken-users
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] POST and GET request parameters from spiffy

[Stephen Eilert]

On Tue, Dec 8, 2009 at 1:17 PM, Peter Bex  wrote:

> On Tue, Dec 08, 2009 at 12:52:00PM -0300, Stephen Eilert wrote:
> > A few days ago I had a difficult bug to diagnose, which happened because
> I
> > was trying to use uri-generic with uri-dispatch, instead of uri-common.
> >
> > What is the purpose of uri-generic anyway?
>
> It is an implementation of RFC 3986, which is much more broadly
> applicable than just in web URIs.  For example, URNs like
> urn:ietf:rfc:3986 are also URIs, but not URI-commons.  They have
> no authority (user/pass/hostname/port combination), and no query
> string either, only a path.  Some other schemes *do* have query
> strings, but not x-www-form-urlencoded ones.
>
> The uri-generic egg is intended for handling the full generality
> of all these types of URIs, whereas uri-common is intended for the
> specific "common" subset of URIs which are usually used on the web,
> to indicate a host, port and path indicating a resource on that host,
> with optionally an x-www-form-urlencoded query to pass to that resource
> for further processing.
>
> uri-common adds a few extra conveniences like more complete path
> decoding (all percent-encoded bits are fully decoded) because it knows
> this is allowed since the path's components are separated by slashes
> but have no additional separators with special meaning inside.  Other
> schemes can't be handled this way.  For example, the URN scheme
> mentioned above has a colon (:) which has special meaning, so %3A could
> not be decoded into : until after the parts are separated;
> urn:foo%3Abar:qux  would be decoded to "foo:bar:qux", and hence it would
> be indistinguishable from urn:foo:bar:qux.
>
> So, to summarize: you would never need or use uri-generic unless you're
> writing a more specific URI parser for other schemes than the common
> ones.
>
>
Thanks for the explanation.


--Stephen

programmer, n:
   A red eyed, mumbling mammal capable of conversing with inanimate
monsters.
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] POST and GET request parameters from spiffy

[Stephen Eilert]

On Tue, Dec 8, 2009 at 8:57 AM, Mario Domenech Goulart <
mario.goul...@gmail.com> wrote:

> Hi
>
> On Sat, 14 Nov 2009 13:01:59 +0100 Christian Kellermann <
> ck...@pestilenz.org> wrote:
>
> > * Michael Maul  [091113 22:38]:
> >> Could someone describe how to access POS and GET parameters from inside
> >> spiffy?
> >
> > (uri-query (request-uri (current-request will get you the GET
> > parameters as alist.  I am not sure about POST. In chicken3 there
> > used to be a convenience function in spiffy-utils.
>
> Beware that you should use uri-common's `uri-query' (not uri-generic's),
> since intarweb's `request-uri' returns an uri-common object.
>
> Best wishes.
> Mario
>
>
A few days ago I had a difficult bug to diagnose, which happened because I
was trying to use uri-generic with uri-dispatch, instead of uri-common.

What is the purpose of uri-generic anyway?



--Stephen

programmer, n:
   A red eyed, mumbling mammal capable of conversing with inanimate
monsters.
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] chicken-doc

[Stephen Eilert]

This is awesome! :)

I can already envision Emacs integration...


--Stephen

programmer, n:
   A red eyed, mumbling mammal capable of conversing with inanimate
monsters.


On Tue, Dec 1, 2009 at 5:03 AM, Jim Ursetto  wrote:

> Hi there,
>
> I've uploaded two new eggs, chicken-doc and chicken-doc-admin, into
> the Chicken 4 egg repository.
>
> chicken-doc allows you to explore Chicken manual and egg documentation
> from the command-line and the REPL.  Documentation is generated from a
> checkout of the wiki, and is stored locally.
>
> To try it out, you will need to install the chicken-doc and
> chicken-doc-admin eggs.  Then generate a new database by following the
> Quick start in http://chicken.wiki.br/eggref/4/chicken-doc-admin.
> Finally, read http://chicken.wiki.br/eggref/4/chicken-doc to learn how
> to use chicken-doc.
>
> Jim
>
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/chicken-users
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Proposed procedure movement in Chicken 4

[Stephen Eilert]

2009/9/10 Matthew Welland 

>
> Seconded. I gave some code of mine to someone with instructions to install
> chicken to compile it. He said it doesn't work. Oops. Yeah, You gotta use
> 3.3. Ok, how do I get it. Uh, dunno. He now thinks chicken is a POS. My
> fault for not testing my directions but annoying none the less. I know you
> guys are stretched thin but please consider making going *back* to 3.3 or
> similar easy and obvious from the chicken home page. 4.X should be marked as
> experimental until 80 or 90% of the eggs work IMHO.
>
>
> In other words 4.X is exciting and all but some of us are using chicken to
> get things done and can't afford exciting ...
>

Many eggs are not necessary anymore (like the myriad of html-generation
ones, with sxml-transforms). Where did you get your 80% figure?

You could also provide a list of eggs that are missing for *your usage*. Or
even try porting some.


--Stephen

programmer, n:
   A red eyed, mumbling mammal capable of conversing with inanimate
monsters.
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Problems installing intarweb

[Stephen Eilert]

On Wed, Apr 22, 2009 at 4:00 PM, Jim Ursetto  wrote:

> 2009/4/22 Stephen Eilert :
> > Hi peeps,
> > I'm trying to install intarweb on my machine
> > uri-generic installs fine, however:
>
> > uri-generic  version:
> 1.12
> > It installs version 1.12 and intarweb requires > 2.0. I've been told on
> IRC
> > that I should use the latest svn trunk and this issue should be fixed.
>
> Stephen,
>
> I will guess the upstream servers (galinha and kitten-technologies) also
> need
> to be updated.  For now, you can either run chicken-install inside a copy
> of the SVN repository for that egg, or direct chicken-install to use a
> particular version:
>

I'll have to run against the repository. Passing the version seems to work -
for the specific egg. It breaks again when dependent eggs are installed.

--Stephen

programmer, n:
   A red eyed, mumbling mammal capable of conversing with inanimate
monsters.
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] Problems installing intarweb

[Stephen Eilert]

Hi peeps,

I'm trying to install intarweb on my machine (uname -a: Darwin
Typhoon-2.local 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST
2008; root:xnu-1228.9.59~1/RELEASE_I386 i386) and I'm hitting some problems
with uri-generic.

uri-generic installs fine, however:

chicken-status
defstruct ... version:
1.2
matchable . version:
2.4.2
uri-generic  version:
1.12

It installs version 1.12 and intarweb requires > 2.0. I've been told on IRC
that I should use the latest svn trunk and this issue should be fixed. Just
to confirm:

Typhoon-2:~ stephen$ csi

CHICKEN
(c)2008-2009 The Chicken Team
(c)2000-2007 Felix L. Winkelmann
Version 4.0.2 - SVN rev. 14347
macosx-unix-gnu-x86 [ manyargs dload ptables applyhook ]
compiled 2009-04-22 on Typhoon-2.local (Darwin)

So it is SVN trunk and chicken-install still installs the older version. The
behavior is slightly different and it seems that I'm hitting another bug:

The following installed extensions are outdated, because `intarweb' requires
later versions:
  uri-common (??? -> 0.2)

(uri-common is currently not installed). If I say yes, then:

removing previously installed extension `uri-common' ...
Error: (open-input-file) cannot open file - No such file or directory:
"/usr/local/lib/chicken/4/uri-common.setup-info"

As expected, it is not installed.

Let's try installing by hand:

The following installed extensions are outdated, because `uri-common'
requires later versions:
  uri-generic (1.12 -> 2.1)

YAY! So I say I wish to replace...

Error: the required extension `uri-generic' is older than 2.0, which is what
this extension requires - please run

  chicken-install uri-generic

So it seems that it still wants to install the old one. I have run out of
ideas, sort of downloading the egg myself and running chicken-install
locally. Any other ideas?


--Stephen

programmer, n:
   A red eyed, mumbling mammal capable of conversing with inanimate
monsters.
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Chicken 3.4 Ubuntu packages

[Stephen Eilert]

Well, if it is Ubuntu-only, you could try a PPA as well.

--Stephen

programmer, n:
   A red eyed, mumbling mammal capable of conversing with inanimate
monsters.


On Thu, Mar 26, 2009 at 8:11 AM, underspecified wrote:

> Greetings,
>
> I noticed that the Chicken packages in Ubuntu are horribly out of date,
> so I have built the Chicken 3.4 debs hosted on chicken.wiki.br and am
> hosting them on my repository Ubuntu-NLP
> [http://cl.naist.jp/~eric-n/ubuntu-nlp/
> ].
> You can install them as follows:
>
> 1) Add Ubuntu NLP to your /etc/apt/sources.list file:
>
> # Ubuntu-NLP 
> 
> >
> deb 
> http://cl.naist.jp/~eric-n/ubuntu-nlp
>  
> scheme
> deb-src 
> http://cl.naist.jp/~eric-n/ubuntu-nlp
>  
> scheme
>
> where  is one of the following: gutsy, hardy, intrepid
>
> 2) Add my public key to your keyring for package verication:
>
> wget 
> http://cl.naist.jp/~eric-n/ubuntu-nlp/8ABD1965.gpg
>  -O-
> | sudo apt-key add -
>
> 3) Refresh the apt sources:
>
> $ sudo apt-get update
>
> 4) Install chicken-bin;
>
> $ sudo apt-get install chicken-bin
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following extra packages will be installed:
>  libchicken-dev libchicken3 libpcre3-dev libpcrecpp0
> The following NEW packages will be installed:
>  chicken-bin libchicken-dev libchicken3 libpcre3-dev libpcrecpp0
> 0 upgraded, 5 newly installed, 0 to remove and 1 not upgraded.
> Need to get 5691kB/6046kB of archives.
> After this operation, 22.3MB of additional disk space will be used.
> Do you want to continue [Y/n]? y
> ...
>
> 5) Enjoy the latest chicken under Ubuntu
>
> $ csi
>
> CHICKEN
> (c)2008 The Chicken Team
> (c)2000-2007 Felix L. Winkelmann
> Version 3.4.0 - linux-unix-gnu-x86-64   [ 64bit manyargs dload ptables
> applyhook ]
> SVN rev. 11987  compiled 2009-02-27 on thyme (Linux)
>
> #;1>
>
> Let me know if you have any questions or comments.
>
> Eric Nichols
> Computational Linguistics Laboratory
> Graduate School of Information Science
> Nara Institute of Science and Technology
>  
> http://cl.naist.jp/~eric-n/
>
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/chicken-users
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] SDL egg: SDL_GL_SwapBuffers() not implemented?

[Stephen Eilert]

On Feb 15, 2009, at 11:51 PM, Koen Weddepohl wrote:


I managed to download the changes through chicken-setup now.

sdl-gl-swap-buffers works fine, the graphics are displaying.

The functions sdl-gl-set-attribute and sdl-gl-get-attribute are  
recognized, but when I call sdl-gl-get-attribute it doesn't seem to  
return the value I've set with sdl-set-attribute. I'm not sure if  
I'm doing something wrong, I haven't used these two functions before.


Cheers,

Koen Weddepohl




Did you actually have to use the sdl-get-attribute and sdl-set- 
attribute for the graphics to display?



Stephen


___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] SDL egg: SDL_GL_SwapBuffers() not implemented?

[Stephen Eilert]

On Tue, Feb 3, 2009 at 2:40 PM, felix winkelmann  wrote:

> On Tue, Feb 3, 2009 at 2:08 PM, Koen Weddepohl 
> wrote:
> > Greetings,
> >
> > I'm interested in using Chicken for homebrew game development.
> >
> > Anyway, I've been trying to get the SDL egg to work with the OpenGL egg.
> > However, I can't get any OpenGL graphics to display. I think this is
> because
> > I can't find an equivalent for SDL_GL_SwapBuffers() in the SDL bindings.
> Am
> > I correct in thinking this is function is not implemented in the SDL egg?
> >
>
> Hi, Koen!
>
> This may very well be the case. I'll try to add this, ASAP.
>
> Note that you can get access to this function quickly using
>
> #>
> #include 
> <#
>
> (define sdl:gl-swap-buffers
>  (foreign-lambda void "SDL_GL_SwapBuffers"))
>
>
It's been a while since I've last tried using SDL with OpenGL, but that's
not the only function that's missing. I had to set a few more things to get
the program to display anything. Too bad I lost my modified SDL egg.

Here's the initalization code I was using:

(define (open-viewport width height)
  (initialize-video-mode width height 0 (+ SDL_OPENGL)))

(define (initialize-video-mode width height bpp flags)
  (sdl-wm-set-caption "OpenGL Window" "OpenGL Window")
  (sdl-set-video-mode width height bpp flags)
  (sdl-gl-set-attribute SDL_GL_DOUBLEBUFFER 1)
  (sdl-gl-set-attribute SDL_GL_RED_SIZE 5)
  (sdl-gl-set-attribute SDL_GL_GREEN_SIZE 5)
  (sdl-gl-set-attribute SDL_GL_BLUE_SIZE 5)
  (sdl-gl-set-attribute SDL_GL_DEPTH_SIZE 16))


For some reason I still cannot understand, the program didn't work without
setting those flags first.


--Stephen

programmer, n:
   A red eyed, mumbling mammal capable of conversing with inanimate
monsters.



>
> cheers,
> felix
>
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/chicken-users
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Is the GTK+ egg still alive?

[Stephen Eilert]

Sorry for the late reply, didn't see the message before.

I'm also willing to contribute, if necessary.


--Stephen

programmer, n:
 A red eyed, mumbling mammal capable of conversing with inanimate monsters.


On Sat, May 31, 2008 at 9:29 PM, Elf <[EMAIL PROTECTED]> wrote:
>
> I was working on it, but I've been sidetracked into some build system fixes.
> Apologies.  If you want to take over, feel free!
>
> -elf
>
>
> On Sun, 1 Jun 2008, felix winkelmann wrote:
>
>> On Tue, May 27, 2008 at 4:28 AM, John Maxwell <[EMAIL PROTECTED]> wrote:
>>>
>>> Gentlefolk-
>>
>> Uh oh - late reply. Sorry.
>>
>>>
>>> Is the GTK+ egg still a live project? I poked around a bit, and it looks
>>> like the project started off OK, but I couldn't find any signs of recent
>>> activity.
>>
>> AFAIK, nobody is really taking care of in the moment.
>>
>>>
>>> This is a thing which would make my life much more pleasant; enough so
>>> that I'd be willing to spend some time and effort on it, if the basic
>>> problem is a lack of people working on it.
>>
>> I think that would be great - I'm not aware of any serious problems with
>> it,
>> just that it has no maintainer. Please, feel free to dig into it.
>>
>>
>> cheers,
>> felix
>>
>>
>> ___
>> Chicken-users mailing list
>> Chicken-users@nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/chicken-users
>>
>
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/chicken-users
>


___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] documentation issues...

[Stephen Eilert]

a r wrote:


I don't want any API docs automatically generated from source code
comments - when separated from the code these comments are just a pile
of useless random notes. Documentation _must_ be written in separation
from the code. Yes, it is an additional effort, bu if you can't afford
it simply don't bother writing any documentation.
  
I think what is meant by "source code comments" is parseable comments in 
the source code, intended for tools to generate and update documentation 
automatically, possibly with their own tags to add semantics. Look up 
Doxygen (http://en.wikipedia.org/wiki/Doxygen) and check out the example 
source code and generated docs. Granted, that's not Scheme, but 
hopefully that's enough to understand the idea. **


It not as if such a tool is going to detect each and every comment 
everywhere and create a useless pile of random comments. That would, 
indeed, be useless. Usually, this type of documentation is brief, just 
giving a general idea of what the function does, which arguments are 
required (and what they mean) and the expected output. How's that 
different from what's being done, for instance, in the sqlite3 egg? 
(http://www.call-with-current-continuation.org/eggs/sqlite3.html)


If you need more than that, then a "manual" is called for. Or even a 
"tutorial". And that can and should be kept in some other location, 
provided it is easily accessible.


If you keep them apart, you cannot see at a glance (let's say, while 
adding features or fixing bugs) if the docs are out-of-date or if 
someone forgot to comment something. Furthermore, the authors have no 
need to look up documentation at all, so the documentation *will* become 
outdated. It's the users that need it, and those aren't always familiar 
with the code to spot the inconsistencies.


Of course, you can keep the docs wherever you want, provided you have 
enough minions you can slap to bring all of them up-to-date :)


Stephen


"Statistics are like humans. Torture them enough and you can make them admit 
anything you want"



___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Re: Debian slander?

[Stephen Eilert]

felix winkelmann escreveu:

On Dec 20, 2007 11:50 AM, Tobia Conforto <[EMAIL PROTECTED]> wrote:
  

Robin Lee Powell wrote:


http://packages.debian.org/sid/chicken-bin

It certainly seems production quality and decently performant to me;
does the Chicken community still agree with the statements there?
  

I find them biased and misleading.  Those statements, coupled with the
maintainer's laziness in updating the packages, are probably turning
quite a few people away from Chicken.  Either he is acting in bad faith,
or he's lost interest in it.  In any case I would welcome a change.




I actually contacted the maintainer a while ago asking for a change
of the description - AFAIK he wanted to do that but perhaps he forgot.

  
Perhaps it would be best for us to brainstorm what the new description 
is going to be and then submit it once it is complete, for them to 
review and include in the new packages.


In addition, the description should say something about Chicken itself. 
As it stands, anyone who has read Cheney's paper probably already knows 
about Chicken, so it should be more of a footnote. There's no mention 
about eggs either, and that (along with the C generation) should be one 
of the major selling points.



Stephen


___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users