Re: How should we deal with weak refs to finalizable objects? (was: Re: [PATCH] Bugfix and drop weak references to finalizable objects (was: Re: [PATCH] thread-safe handling of asynchronous events))
Hi,
I think this clears things sufficiently up.
Please excuse me if I am missing some details...
Strong references are already ensured to be gone
and weak references are cleared using the incantations that sjamaan
(in his wisdom) proposed
What is the definition of a weak reference in this case?
One definition is that weak references only refer to the object if there
are one or more strong references to the object.
In this case, all the strong references are gone before the finaliser runs
and therefore all the weak references are semantically invalid already.
Whilst the finaliser is running there are no strong references to the
object but it's possible (if the finaliser decides to resurrect the object)
that there will once again be a strong reference to the object (e.g. if the
finaliser set!s it).
But then, as you say, it's reincarnated: a new object that will never be
more than equal? (and certainly not eqv? or eq?) to the old one.
Everything's consistent in this model because the references that the GC
has to objects are neither "weak" nor "strong" but merely an implementation
detail hidden from the outside.
This seems to be the definition that sjamaan is using.
Another definition is that weak references can refer to an object that is
still "in memory".
This way lies disaster because then the semantics of weak references are
dependent on specific implementation details.
I think here we're struggling with the atomicity of the garbage collector
because the finaliser is special user code that executes inside the garbage
collector's "transaction" and that code has all the power and capabilities
of any other scheme code.
What happens if there are a circular list of objects all of which have
finalisers?
The CHICKEN GC usually handles circular lists well, but when this one is
collected (i.e. there are no external strong references to the list
anymore) all its members come up for finalisation at the same time.
Which order are the finalisers called in?
...and which of the other objects can be seen from the object that is
finalised first?
This is similar to the argument above about the correct definition of weak
pairs.
To preserve atomicity there needs to be no "happens before" or "happens
after" relationships between things that happen in a single GC cycle
(transaction).
If weak pairs are not *already* invalid by the time the finaliser runs then
it's possible to see into the GC transaction because the weak pair
invalidation can be observed to "happen after" the GC cycle.
When the managed memory for the circular list is freed it does not matter
precisely which order it is freed in because there are no side effects of
freeing it and it all happens in a single GC cycle.
But when the finalisers are run the user's code will see these objects in
various different states depending on the order.
So how can we finalise a circular list of objects all of which have
finalisers and still maintain atomicity?
The docs say the order is "undefined".
It seems that the best way to finalise this structure is to explicitly
break all the strong references between components of the list (as we do
for external weak references) before any of the finalisers are called.
It may also improve the memory model if we define the object that the
finaliser receives as a "copy" of the object that has ("already") been
garbage collected.
Best wishes,
@ndy
--
andy...@ashurst.eu.org
http://www.ashurst.eu.org/
0x7EBA75FF
Re: Plan for support of UTF-8 in core system
Hi, Bevuta IT GmbH has kindly agreed to sponsor some work on CHICKEN and I suggest to start on full unicode support in the core system, getting rid of the current solution with a bolted-on utf8 egg. http://wiki.call-cc.org/unicode-transition This is great news and very exciting! Thanks Bevuta and Felix! Best wishes, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF
Re: [Chicken-hackers] PATCH: wrong type for alist-delete!
Hi Peter, > It occurred to me that maybe the scrutinizer is smart enough to merge > lists of pairs of (known) mixed types, and it actually is! > > (use srfi-1) > (print (assoc 'x '((1 . 2) (#f . 4)) (lambda (x y) (> x y > > When compiled, this will tell you: > Warning: at toplevel: > (test.scm:2) in procedure call to `assoc', expected argument #3 of type > `(procedure ((or false fixnum) symbol) *)', but was given an argument of type > `(procedure (number number) boolean)' > > So I guess my patch needlessly weakens the type declarations. What happens when the alist argument to assoc isn't static? Does the data analysis know the types? Which type is better for safe code generation in the non-static data case (which I imagine to be the general case). Is there a difference between building the alist up dynamically with alist-cons compared to using quasiquote or cons or something? Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0290 DA75 E982 7D99 A51F E46A 387A 7695 7EBA 75FF signature.asc Description: OpenPGP digital signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Add a statistical profiler
Wow! This is excellent and just what I need. Thanks Peter! > For a while now I've been meaning to improve our profiler. I finally > got around to writing a new profiler a few weeks ago and I've been > testing it on and off since then. I think now it's ready to start > integrating it. I've successfully made some performance improvements in > uri-generic and intarweb. The irregex performance improvement I sent to > chicken-hackers was also a result from running it with the new profiler. > > I believe the profiler needs improving because of these limitations: > > * Instrumentation adds a whole lot of overhead and prevents various >optimizations due to requiring dynamic-wind and turning all calls >to such procedures into a CPS call. This skews the results, >sometimes so extremely to make the profile output useless. >If you want to see an example of this, try profiling the "nbody" >benchmark from Mario's chicken-benchmarks repo. It goes from >1s to 17s on my laptop. Other examples include "knucleotide", >"primes" and "ray2". > * Only toplevel procedures are instrumented. This means that programs >with large procedures or programs which rely heavily on closures will >be hard to profile. It's possible to work around this by tweaking >the source code, but this is very annoying to do. > * Checking performance of a program requires recompilation with >-profile. This is only a minor annoyance, but sometimes you >want to look "deeper" inside the library calls that your program >performs, and that means you'll have to recompile those libraries >with -profile as well (and possibly libraries they use, and so on), >which gets annoying pretty quickly. Also, you can easily forget you >did that for a library, and this will slow down all programs using >this library. > > The attached patches add a *second* profiler to CHICKEN, which uses > statistical sampling to figure out where a program spends most of its > time. It registers a timer with setitimer(). This will trigger a > signal to be delivered every 10ms (this is customisable via "-:P"). > > When a signal arrives, we look at the top of the trace buffer to > find the currently running procedure. This means it needs *no* > additional instrumentation or even recompilation: libraries or > programs which are compiled without -no-trace or -d0 (i.e., most > of them) are instantly profileable! > > This statistical sampling method is basically what gprof(1) and profil(3) > also do, from what I understand of their documentation. > > To see it in action, just compile the target program as normal, and then > when running it, pass it the "-:p" switch. This is recognised by the > runtime system and therefore any program can be passed this switch. > On exit, it will write out a "PROFILE.1234" file, where 1234 is the pid, > just like under the instrumentation-based profiler. This can only be > read with the new version of chicken-profile, which I've tweaked a tiny > bit to understand the new profile format, which has a header now. > > The tweak to chicken-profile is necessary because the statistical > profiler has very little context to work with: it only sees the top > of the trace buffer, so it knows what procedure is currently running. > Because it takes a sample every 10 ms, it can count how much time > is spent in that procedure, but it doesn't really know how it got there, > as it can't carefully track procedure entry/exit events like the > instrumentation does under the old profiler. > > So, we know how much time is spent in a procedure, we can only calculate > the percentage of the entire running time spent, individually per > procedure. This means the percentages add up to 100, which is different > from the original profiler. There, the percentage will be 100 for the > "main" procedure, and less for everything called by it. Because of this, > both profilers now write a "header" symbol to the start of the profile, > which chicken-profile recognises and will change its behaviour on. > > The new profiler has none of the disadvantages of the old profiler, but > comes with its own set of caveats: > > * If a program blocks signals, profiling is unreliable. I got a report >from Kooda that SDL's vsync() seems to do this, so this is not always >directly under the programmer's control. > * The profile results are very different: it shows how much time is >spent in the procedure that was called last, making it very low-level. >This can sometimes result in a harder to read profile, with lots of >details. >The old profiler would simply state "procedure X is slow", while the >new will say "call (A) on line 1 is slowest followed by call (B) on >line 1507 and call (C) on line 5", even though lines 1 and 5 are both >part of procedure X. Ideally you would want some way to sum the >calls belonging to the same procedure. On the other hand, it can >
Re: [Chicken-hackers] [Chicken-users] Any thoughts on performance woes?
Hi, The difference is, this one is much better code, which doesn't exercise the garbage collector, so it isn't much use as a GC benchmark. Code involving SSQL would be good for a GC benchmark. I recently reworked the query generation in Knodium to be up-front rather than at access-time and got an ordes of magnitude speed up and an order of magnitude fewer GCs. Here's a snippet from my commit message: - (account 'read 1:3) query generation (each call returns 1 account object) (time (for-each (lambda x (account 'read 1:3)) (iota 6500))) Original: 5.296s CPU time, 0.492s GC time (major), 3334265 mutations, 86/28886 GCs (major/minor) 5.357s CPU time, 0.48s GC time (major), 3334265 mutations, 84/2 GCs (major/minor) 5.332s CPU time, 0.508s GC time (major), 3334265 mutations, 89/28883 GCs (major/minor) 5.284s CPU time, 0.46s GC time (major), 3334265 mutations, 83/28889 GCs (major/minor) 5.397s CPU time, 0.501s GC time (major), 3334283 mutations, 83/28889 GCs (major/minor) With pre-generated query in read-account: 0.304s CPU time, 0.004s GC time (major), 220077 mutations, 1/656 GCs (major/minor) 0.296s CPU time, 220077 mutations, 0/657 GCs (major/minor) 0.304s CPU time, 220077 mutations, 0/657 GCs (major/minor) 0.296s CPU time, 220077 mutations, 0/657 GCs (major/minor) 0.3s CPU time, 220077 mutations, 0/657 GCs (major/minor) - Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0290 DA75 E982 7D99 A51F E46A 387A 7695 7EBA 75FF signature.asc Description: OpenPGP digital signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Made a start with CHICKEN 5 proposal
Hi, * Please use long, explicit library names, it's easier to remember (there are many ways to abbreviate something, but only one way not to - I forgot who said this, John will tell me, I'm sure.) And I would also suggest to avoid using srfi-XXX as a module name, and to use something meaningful (yes, I know that in the past I was largely responsible for that mistake in numerous situations.) That would also allow adding our own extensions. This is a good point and comes up time and again (in IRC). The most functionally important thing seems to be the way module names interact with portable code. Isn't srfi-XXX the only portable way to do it? Isn't long names the only friendly way to do it? Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
Hi, The Chicken wiki still has an index of Chicken 3 eggs, although I do think chicken-setup is no longer operational. Perhaps now would be a good time to clean the wiki of vestigial references to 2 3. AIUI, this documentation is preserved for posterity and in case anyone wants to forward port any of the remaining un-ported stuff. The code is still in SVN so it makes sense to keep the docs as well. The main issue is that this older stuff shows up in searches and confuses new users. Perhaps we should do something about that and more clearly mark the pages themselves as deprecated? Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
Hi, I'd love to hear from some of the people using CHICKEN in their business or for other Serious Projects (Kristian? Ivan? Andy?) how painful this would be for them. After taking some time to familiarise myself with them, these all sound like big and important changes. It took us a long time to migrate from 4.7 - 4.9 and I expect that we will be happy with 4.9 for quite some time to come yet. As such, when we come to upgrade we would expect that it would be some work for us. It may even be possible to do some parts of the work, such as splitting srfis out of core, in 4.X as these will not require .scm sourcecode changes; only metadata changes. Would the intention be to move all primary development effort over to the 5 branch? How would 4.9 stability releases work? Most of the proposed 5 work is cleanup. Where would feature work be expected to be done? What work would be done before the first stable 5 release and what work would come in point releases after that? Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] mmap
Hi, There is no way to do this. By messing around with Linux-specific mmap() flags, you can get Linux to prepage the whole file, paying the entire cost at once, Yes. These methods don't strike me as a very good way forward. I was thinking more along the lines of executing FFI calls in a (pool of?) pthreads. That would solve the issue for mmap callers as well as any APIs which had underlying blocking calls of any type. Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] mmap
Hi, Andy, can you elaborate on the blocking scenario you are seeing? My particular scenario is that I'm using SQLite with a pool of many database connections and I'm seeing those connections use a lot of memory that could be shared by using the SQLites mmap functionality rather than it's traditional read/write model. In weighing up the pros and cons I realised that these mmap calls would unpredictably block in the FFI. I then realised that the existing read calls are probably also blocking in the FFI but haven't had a chance to profile or measure it yet: It's a bit of a yak shaving exercise given that my current actual goal is to manage memory usage better. Once I've done that I'll be more interested in the actual performance issues. Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] mmap (was: Re: library unit restructuring)
I'm resending this as I don't appear to have received it back from the list?? Original Message Subject: mmap (was: Re: [Chicken-hackers] library unit restructuring) Date: Wed, 09 Jul 2014 14:56:38 +0100 From: Andy Bennett andy...@ashurst.eu.org To: Felix Winkelmann felix.winkelm...@bevuta.com, chicken-hackers@nongnu.org Hi, - memory-mapped-files Without wishing to hijack the entire thread, as an aside, is there any way of making memory mapped files play nicely with the CHICKEN scheduler and threading model? It's possible for memory mapped files to cause a page fault which will then wait for I/O and, as I understand it, that will block the entire runtime. The background to this is that I've been thinking of switching on mmap support in my SQLite database. AIUI, the Sqlite API is blocking anyway and even the existing read calls underneath the FFI call with block the runtime. Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] mmap (was: Re: library unit restructuring)
Hi, - memory-mapped-files Without wishing to hijack the entire thread, as an aside, is there any way of making memory mapped files play nicely with the CHICKEN scheduler and threading model? It's possible for memory mapped files to cause a page fault which will then wait for I/O and, as I understand it, that will block the entire runtime. The background to this is that I've been thinking of switching on mmap support in my SQLite database. AIUI, the Sqlite API is blocking anyway and even the existing read calls underneath the FFI call with block the runtime. Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [Chicken-users] 4.9.0rc1: Error: (assv) bad argument type: null
Hi, The error on 4.9.0rc1 is likely due to 0a52536, which made `assoc`, `member` et al. signal errors when their second arguments aren't lists instead of just returning #f (or the sentinel value). This is new behavior since 4.7.0, and IIRC there were a couple of places in CHICKEN itself that required updating after this change too, since they were also relying on these cases returning #f. Anyway, when passed `eqv?` as a comparator *before* importing numbers, `alist-ref` uses CHICKEN's built-in `assq` for the search, including this new behavior. *After* importing numbers, however, you're really passing the numbers extension's version of `eqv?`, which `alist-ref` doesn't take as a signal to use the built-in `assq` and instead falls back to a search function that matches the pre-0a52536 (i.e. 4.7.0) behavior and returns #f/the sentinel value. Thanks for the detailed reply Evan! :-) Of course, my code is wrong but it was the inconsistent behaviour with and without numbers that I was worried about. I shall change my code to be correct. This should mean that I will be able to use 4.9.0rc1 to build working binaries for Knodium that I will deploy at https://www.knodium.com/ Are the CHICKEN web services currently built with 4.9.0rc1? @ -hackers: I think `alist-ref`'s fallback search function should match the behavior of core's versions. Objections? I agree. Thanks for the patch Peter. Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [Chicken-users] [PATCH] Re: 4.9.0rc1: Error: (assv) bad argument type: null
Hi, + (assert-error (alist-ref 'foo 'bar cmp)) + (assert-error (alist-ref 'foo '(bar) cmp))) What's a good predicate to use to check whether what will be passed to alist-ref will not throw an exception? The 2nd assert-error rules out a simple list? or an O(1) algorithm. (Tho' list? is already O(n)). Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Let's make a release!
Hi, Now that #877 is (hopefully) fixed, I'd like to start the prerelease process. I'll merge the manual somewhere this weekend and then merge the master branch into prerelease, unless anyone objects. I think the remaining open tickets should probably be postponed till after the release. It's taken long enough and these tickets don't substantially improve the situation when fixed, IMHO. Of course we need the #877 fix tested some more, so we'll have to wait for at least a few results, but I think it's also a good time to have the community do some serious testing on our supported platforms. If anyone has any important patches that have to go into this release, feel free to post them. Horray! Good work! We're really looking forward to testing this at Knodium. We're still using 4.7. Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [Chicken-users] Redefinition of imported binding gets implicitly exported
Hi, I looked into this recently since it also seemed like a bug to me, but the behavior seems to be intentional judging from the code. Even if the behaviour is intentional, there is possibly still a bug. This worked find on my own machine but failed on others so the implicit ordering of something somewhere seems to matter. A workaround is to exclude `process` from the import list in `m` (as in `(import (except posix ...))`) -- this prevents the behavior you're seeing, at least. I need is in some places tho', and if it's used anywhere in a program, it takes over the binding everywhere and seems to become implicitly available everywhere. When `##sys#alias-global-hook` is used to resolve an identifier name for an assignment, it's called with the already-looked-up name from the environment and shortcuts when that identifier is already aliased, returning the imported name (in this case, the built-in `process`) rather than a new, module-prefixed identifier that would shadow the binding like you said. It seems to me that when `##sys#alias-global-hook` is used to resolve names for `set!` forms, it should be called with the bare (pre-se-lookup) identifier, and when `assign` is true and you're currently in a module it should always create a module-prefixed identifier and update the environment, instead of returning the existing alias for imported symbols. But, I couldn't get this to work without breaking other things. CC'ing -hackers. Evan ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] r7rs modules
Hi, Ideas? What does R7RS have to say about the keyword use? Are we free to have, say use* ? Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] will we have a release this year?
Hi, The environments egg will not work under Chicken 4.7.4 and later, due to changes in the internal representation (also noted in the documentation). The rewrite branch is meant to fix this issue. This was an error from the rewrite branch. We were wondering whether an internal error such as the one reported would be from chicken or the egg. Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] will we have a release this year?
Hi, I have been testing 4.8.0rc4 quite a bit this week, and everything seems to work fine, so if there are no objections, I will make the release next Monday. Did people see my bug report on chicken-users regarding the environments egg and eval? I posted in the Re: [Chicken-users] Chicken 4.8.0 release candidate 4 now available thread on 2012/09/18. -- Another was segfaulting and continued to segfault on 'load'. I narrowed it down to this repro case in the interpreter: - #;1 (use environments) #;2 (define widget-eval-env (make-parameter (environment-copy (scheme-report-environment 5) #t))) - Using Mortiz's rewrite branch of the environments egg: https://anonymous:@code.call-cc.org/svn/chicken-eggs/release/4/environments/branches/rewrite/ ... stops the segfault. I can get a binary out but it throws an exception somewhere it didn't used to: - unbound variable ##sys#list - ...and my debugging efforts so far point to a problem with eval and an environment from the environments egg. -- Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] Summer 2012 meetup in the UK?
Hi, Having just moved into a much larger house than I previously lived in (one large enough to have an actual guest room, plus a playroom for the kids that we're equipping as a second guest room, and a big lounge!), I hereby offer to host a Chicken meetup sometime this summer! We can easily sleep quite a lot of people here (particularly if they bring sleeping bags). Tops! I'm already looking forward to it and EXCITED! The location is Gloucester, which is about an hour and a half from London by train. As well as having a few days' hacking, we should find time to go and visit some of the lovely attractions of the area, such as the legendary cheese shop in Cheltenham, or peering at GCHQ, which is Europe's largest supercomputer centre (through a barbed-wire fence, while watched suspiciously by armed guards), or going for strolls in the Cotswold countryside. If you're in London, be sure to visit Cons Street: http://g.co/maps/z4rhs And I must warn everyone that my wife is planning to bake Chicken-themed cakes and biscuits. CHICKEN CAKES?!?!? I am open to suggestions for dates. Should I avoid the Olympics, as travel will presumably be more expensive then? Or should I coincide with the Olympics, as people might want to come over to the UK for them anyway, and sneak in a few days in Gloucester amongst it all? Who would like to come, and when can they get time off? I'd recommend we make it a long weekend, so we can fit in a good mixture of hacking and adventuring! But people are welcome to stay for longer if there's interest :-) How about the August Bank Holiday? Although I'm not sure how many UK people there are and whether it coincides with bank holidays elsewhere? Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF signature.asc Description: OpenPGP digital signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [Chicken-users] happy new year!
Hi, A happy and successful new year to all of you! Happy New Year! For those who are waiting: Gazette 22 is on its way: I got a bit busy towards the end of 2011. Thank you for all the contributions I have received. Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
