Re: SRFI-143 Fixnums (was Generalized-Arrays egg v1.0.1)
On 4/22/24 22:20, Diego wrote: On Monday, April 22nd, 2024 at 11:56 PM, Jeremy Steward wrote: Sorry to reply to myself, but I've provided some better patches now, see attached. Whoops, I got this in the middle of pushing the previous change. I'll try and apply the new patches. Thanks for this. Diego Thanks for applying those patches and pushing up v1.0.0. I tested the re-exports locally and they seem to no longer cause performance problems on transducers or generalized-arrays, and new versions of those should be up shortly. Cheers, -- Jeremy Steward
Re: SRFI-143 Fixnums (was Generalized-Arrays egg v1.0.1)
Sorry to reply to myself, but I've provided some better patches now, see
attached.
I went ahead and fixed the Makefile and SVNWiki pages as well. I can't
run test-new-egg but salmonella passes just fine.
Cheers,
--
Jeremy StewardFrom 0fe5cff9482bc6a11594d907128ddbcad562976c Mon Sep 17 00:00:00 2001
From: Jeremy Steward
Date: Mon, 22 Apr 2024 21:54:21 -0600
Subject: [PATCH 3/3] Update svnwiki page with appropriate docs
---
srfi-143.svnwiki | 43 +--
1 file changed, 21 insertions(+), 22 deletions(-)
diff --git a/srfi-143.svnwiki b/srfi-143.svnwiki
index 7f326e9..fd4be26 100644
--- a/srfi-143.svnwiki
+++ b/srfi-143.svnwiki
@@ -52,11 +52,9 @@ in the same way as {{(chicken fixnum}}).
=== Deviations from the specification
-In the CHICKEN implementation, {{fx+}}, {{fx-}}, and {{fx*}} are variadic,
-implemented with {{foldr}}, {{foldl}}, and {{foldr}}, respectively. For
-completeness, a variadic {{fx/}} is provided as well, implemented with
-{{foldl}}. It's not clear that this is much more useful than the SRFI's
-{{fxquotient}}.
+All procedures in this library are 2-arity wherever possible. The original
+SRFI-143 document lists these procedures as variadic, but for compatibility
+with {{(chicken fixnum)}} these are kept to 2-arity and re-exported.
=== Specification
@@ -105,23 +103,23 @@ Bound to the value {{-2^w-1}}, the smallest representable fixnum. (R6RS
Returns {{#t}} if obj is an exact integer within the fixnum range, and {{#f}}
otherwise.
-(fx=? i ...)
+(fx=? i j)
Semantically equivalent to {{=}}.
-(fx
+(fx
Semantically equivalent to {{<}}.
-(fx>? i ...)
+(fx>? i j)
Semantically equivalent to {{>}}.
-(fx<=? i ...)
+(fx<=? i j)
Semantically equivalent to {{<=}}.
-(fx>=? i ...)
+(fx>=? i j)
Semantically equivalent to {{>=}}.
@@ -145,21 +143,21 @@ Semantically equivalent to {{odd?}}.
Semantically equivalent to {{even?}}.
-(fxmax i j ...)
+(fxmax i j)
Semantically equivalent to {{max}}.
-(fxmin i j ...)
+(fxmin i j)
Semantically equivalent to {{min}}.
Basic arithmetic
-(fx+ i ...)
+(fx+ i j)
Semantically equivalent to {{+}}.
-(fx- i ...)
+(fx- i j)
Semantically equivalent to {{-}}.
@@ -167,11 +165,11 @@ Semantically equivalent to {{-}}.
Semantically equivalent to {{-}}, but accepts exactly one argument.
-(fx* i ...)
+(fx* i j)
Semantically equivalent to {{*}}.
-(fx/ i ...)
+(fx/ i j)
Semantically equivalent to {{(foldr quotient i rest-args)}}.
@@ -243,15 +241,15 @@ are dropped for brevity and compatibility.
Semantically equivalent to {{bitwise-not}}.
-(fxand i ...)
+(fxand i j)
Semantically equivalent to {{bitwise-and}}.
-(fxior i ...)
+(fxior i j)
Semantically equivalent to {{bitwise-ior}}.
-(fxxor i ...)
+(fxxor i j)
Semantically equivalent to {{bitwise-xor}}.
@@ -331,17 +329,17 @@ Jaffer, Taylor Campbell, and the R6RS editors.
=== Copyright
Copyright (C) John Cowan (2016). All Rights Reserved.
-
+
Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
of the Software, and to permit persons to whom the Software is furnished to do
so, subject to the following conditions:
-
+
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
-
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
@@ -352,6 +350,7 @@ Jaffer, Taylor Campbell, and the R6RS editors.
=== Version history
+* 1.0.0 - Convert egg to R7RS library & convert variadic procedures to 2-arity procedures.
* 0.4.1 - Fix bug due to calling fixnum procedures with wrong number of arguments
* 0.4 - Implement variadic arithmetic operators, use fixnum operations internally
* 0.3 - Reorganize and reduce files
--
2.43.0
From c9e35def19b4f7c0753180ac395eb0f009b0ac60 Mon Sep 17 00:00:00 2001
From: Jeremy Steward
Date: Mon, 22 Apr 2024 21:29:41 -0600
Subject: [PATCH 2/3] Add chicken-lint to Makefile / clean up makefile
Some of the commands were a bit ??? so I did a bit of cleanup on the
Makefile.
---
Makefile | 36
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/Makefile b/Makefile
index d613d59..7deea33 100644
--- a/Makefile
+++ b/Makefile
@@ -1,25 +1,37 @@
-CHICKEN_CLEAN := chicken-clean
-CHICKEN_INSTALL := chicken-install
-SALMONELLA := salmonella
-SALMONELLA_LOG := salmonella.log
-SALMONELLA_LOG_VIEWER := salmonella-log-viewer
-SRFI := srfi-143.scm
-TEST_NEW_E
Re: SRFI-143 Fixnums (was Generalized-Arrays egg v1.0.1)
On 4/22/24 14:55, Diego wrote: Hi all, Sorry to be very late/unresponsive to this discussion. As I understand it from reading the email thread, there are several optimizations and changes to SRFI-143 that would make it more performant or inline with the intent of the original SRFI. Heyo! Better late than never! I think there's two things being discussed: 1. SRFI-143 as it exists is rather slow compared to (chicken fixnum) 2. There seems to be an errata / post finalization note in SRFI-143 (the text) that needs to be brought up regarding 2-arity vs. variadic procedures in the spec. John mentioned he would pursue this, although looking at the archives I haven't seen it yet. I have unfortunately not had much time for scheme in the past couple years, and though I'd love to get back to it eventually, I'd hate to simply sit on the sources for this (or any other eggs I maintain) without allowing for it to evolve. I understand this feeling. Look at generalized-arrays (thread topic), I sat on it for years! I'd be happy to give Jeremy and anyone else interested in this effort read/write access to the sources at https://git.sr.ht/~dieggsy/srfi-143, or transfer the egg to a different maintainer/repo entirely if that approach is preferred. Diego I don't have a SourceHut account, but from what I know of SourceHut I believe either approach can be made to work (I may need to set up git-send-email). For what it's worth, I've done the hard work of converting everything to an R7RS egg as well as fixing the tests / arity of every procedure to match that of (chicken fixnum) and what I presume to be John's original intent with the SRFI. See the attached file for the full patch. One thing I did not do was update the svnwiki page in the repo. I can definitely do this but I only spent about an hour or so on this and some plugin in my editor is messing with the formatting. (classic excuse right?) Anyways, happy to continue to get this out to folks. I don't know to what extent users are currently using SRFI-143 so I'd be wary to push this out, but I went to the liberty of bumping the version to 1.0.0 since this would definitely be a major breakage of the API. Cheers, -- Jeremy StewardFrom d9d3a770afc54faf12558f59e37a33db7a016587 Mon Sep 17 00:00:00 2001 From: Jeremy Steward Date: Mon, 22 Apr 2024 20:56:03 -0600 Subject: [PATCH] Convert egg to R7RS egg & variadic procedures to 2-arity --- carries.scm | 63 --- srfi-143-impl.scm | 98 - srfi-143.egg | 12 ++- srfi-143.release-info | 1 + srfi-143.scm | 246 +++--- srfi-143.sld | 83 ++ tests/r6rs-test.scm | 176 -- tests/run.scm | 34 +++--- 8 files changed, 270 insertions(+), 443 deletions(-) delete mode 100644 carries.scm delete mode 100644 srfi-143-impl.scm create mode 100644 srfi-143.sld delete mode 100644 tests/r6rs-test.scm diff --git a/carries.scm b/carries.scm deleted file mode 100644 index 8c2253c..000 --- a/carries.scm +++ /dev/null @@ -1,63 +0,0 @@ - Generic implementation of carry functions from the R6RS standard. - -;;; These implementations of fx+/carry, fx-/carry, and fx*/carry -;;; are very inefficient, and should be replaced by proper -;;; assembly language operations if at all possible. -;;; Furthermore, there are no tests for them, -;;; because of their dependency on fx-width. - -(define exp-width (expt 2 fx-width)) - -(define (fx+/carry i j k) - (let*-values (((s) (+ i j k)) -((q r) (balanced/ s exp-width))) -(values r q))) - -(define (fx-/carry i j k) - (let*-values (((d) (- i j k)) -((q r) (balanced/ d exp-width))) -(values r q))) - -(define (fx*/carry i j k) - (let*-values (((s) (+ (* i j) k)) -((q r) (balanced/ s exp-width))) -(values r q))) - -;;; Helper functions from SRFI 151 - -(define (floor-/+ n d) - (let ((n (- 0 n))) -(let ((q (quotient n d)) (r (remainder n d))) - (if (zero? r) - (values (- 0 q) r) - (values (- (- 0 q) 1) (- d r)) - -(define (ceiling-/- n d) - (let ((n (- 0 n)) (d (- 0 d))) -(let ((q (quotient n d)) (r (remainder n d))) - (if (zero? r) - (values q r) - (values (+ q 1) (- d r)) - -(define (euclidean/ n d) - (if (and (exact-integer? n) (exact-integer? d)) - (cond ((and (negative? n) (negative? d)) (ceiling-/- n d)) -((negative? n) (floor-/+ n d)) -((negative? d) - (let ((d (- 0 d))) - (values (- 0 (quotient n d)) (remainder n d -(else (values (quotient n d) (remainder n d - (let ((q (if (negative? d) (ceiling (/ n d)) (floor (/ n d) -(values q (- n (* d q)) - -(define (balanced/ x y) - (call-with-values - (lambda () (euclidean/ x y)) -(lambda (q r) - (cond ((< r (abs
Generalized Arrays v2.0.0
Hello all, It was brought to my attention that the v1.x series of Generalized-Arrays broke some things due to a name collision with the functional arrays egg <https://api.call-cc.org/5/doc/arrays>. To remedy this, I fixed the imports to now be (import generalized-arrays) and released a v2.0.0 (since this is a breaking change). @Mario: I've also changed my default branch to be called 'main'. I'm not sure if you need to update the URL for the release-info file, but you can find it here: <https://gitlab.com/ThatGeoGuy/chicken-generalized-arrays/-/raw/main/generalized-arrays.release-info> Apologies for the inconvenience in the meanwhile. Cheers, -- Jeremy Steward
Re: Generalized-Arrays egg v1.0.1
On 2/4/24 05:11, felix.winkelm...@bevuta.com wrote: 1. The egg itself is not compiled with -O3, whereas if I link to (chicken fixnum) I believe that these procedures will be inlined by the CHICKEN compiler when the arrays egg is compiled with -O3 or higher. That's correct. As -O3 implies "unsafe", the compiler can just ignore type checks and always inline numeric primitives. Awesome, glad my intuition about this wasn't unfounded. This is probably the biggest factor. 2. There may be some rewriting rules that the compiler uses for procedures in the (chicken ...) namespace that optimizes these directly into their equivalent optimized C procedures. I'm not sure the compiler has the same visibility if you re-export these from behind a module, and especially not if you link dynamically (any hope of inlining those is thus gone forever). As a general rule all renamings and rexports preserve the run-time semantics - as long as a procedure definition is not wrapped inside another procedure, the original procedure gets compiled and any optimizations and inlinings the compiler performs for "known" primitives will be applied. Syntax- and module-specific expansions perform renaming only and never introduce run-time code that wasn't explicitly given by the user. Aha, so as long as something is wrapped we don't see the same kind of inlining. In fact on the latter point above, this raises an interesting question I had for the mailing list: if I re-export a CHICKEN-specific procedure, does the way the compiler handles translation units prevent certain optimizations from applying? I've somewhat noticed that to be the case but I haven't seen any writing about it nor have I understood the extent to which that might affect certain SRFIs or eggs. See above - unless something is wrapped, you get the inlining. But as I see in the SRFI-143 spec, their operations take any number of arguments, where the ones from (chicken fixnum) have arity 2, so I assume the srfi code wraps the primitives into multi-argument procedures and thus preserves imports from the srfi-143 module to be inlined. And yup, that's probably it. From what I can tell from the source locally they are wrapped e.g.: (define (fx+ . args) (foldr chicken:fx+ 0 args)) If you have time/energy, it would be useful to make Chicken's implementation do what it was originally intended. See the "Implementation" section in the SRFI, or feel free to ask me for explanations of details. One approach would be to extend those exports from (chicken fixnum) that match the multi-argument operations from srfi-143 and make the compiler aware of these, internally expanding the multi-arg cases into nested applications of inline calls to the 2-argument C runtime primitive ops. So what would this look like? I can see fx+ above, which uses `chicken:fx+` (prefixed, 2-arity) and foldr to accomplish its multi-arg case. Is adding `(inline-file)` to the srfi-143.egg enough for this? I suspect partly that the foldr and `(fx+ . args)` form in general is going to be hard to optimize out, but perhaps a case-lambda is faster? I suppose in pretty much all cases since I'm using the 2-arity versions in the generalized-arrays library there's very little pushing me to use the SRFI-143 versions, but any improvement to SRFI-143 is probably worthwhile considering the kinds of performance differences I was measuring with chicken-profile. It might also be a good idea to enforce SRFI-143's behaviour around overflow / underflow as part of CHICKEN's default behaviour in CHICKEN 6, but I don't really know how I would get started having that discussion. The SRFI-page doesn't seem to specify any behaviour. The runtime system is compiled with "-fwrapv" in the hope to preserve wrapping semantics for integer arithmetic, but I'm not sure how reliable that is. Interesting! I believed the SRFI-143 was specifying twos-complement behaviour, but I now see that I was wrong. I would think in general that if -fwrapv is passed, we should assume that twos-complement is used. Recent C standards have codified this explicitly, but pretty much every major compiler I've used over the last 10 years has all-but-standardized twos-complement as well. I guess as long as the runtime system is always using -fwrapv it isn't a concern. It would be undefined behaviour without that flag though, which I suppose someone could maybe force, with great effort? Either way, probably not worth worrying about. Thanks for the really informed reply Felix, this was very helpful in understanding what's happening with SRFI-143. I can hopefully start crafting a patch for this now. Cheers, -- Jeremy Steward
Re: Generalized-Arrays egg v1.0.1
On 2/3/24 16:03, John Cowan wrote: On Sat, Feb 3, 2024 at 5:39 PM Jeremy Steward <mailto:jer...@thatgeoguy.ca>> wrote: Likewise, I opt to use (chicken fixnum) but this is because I discovered that SRFI-143 is so egregiously slower than (chicken fixnum) that it was causing serious performance regressions in many of the array APIs. That's very odd. The Chicken-specific library wrapper for SRFI 143 at GitHub (srfi-143.scm, which needs to be updated to Chicken 5) makes use of Chicken's native fx* procedures. I don't know how the Chicken (srfi 143) egg was built, though; it may be using rubber-chicken.scm and fxcore.scm, which are slow emulations meant for complete portability. From what I understand on the SRFI page it is in fact re-exporting these procedures and not handling the overflow / underflow of some of the operations. There's this note on overflow on the docs page: <https://wiki.call-cc.org/eggref/5/srfi-143#note-on-overflow> Differences from the intended implementation details aside, I think the core of what was a performance hazard (at least as far as I looked into it) could have been one of two things (maybe both?): 1. The egg itself is not compiled with -O3, whereas if I link to (chicken fixnum) I believe that these procedures will be inlined by the CHICKEN compiler when the arrays egg is compiled with -O3 or higher. 2. There may be some rewriting rules that the compiler uses for procedures in the (chicken ...) namespace that optimizes these directly into their equivalent optimized C procedures. I'm not sure the compiler has the same visibility if you re-export these from behind a module, and especially not if you link dynamically (any hope of inlining those is thus gone forever). In fact on the latter point above, this raises an interesting question I had for the mailing list: if I re-export a CHICKEN-specific procedure, does the way the compiler handles translation units prevent certain optimizations from applying? I've somewhat noticed that to be the case but I haven't seen any writing about it nor have I understood the extent to which that might affect certain SRFIs or eggs. If you have time/energy, it would be useful to make Chicken's implementation do what it was originally intended. See the "Implementation" section in the SRFI, or feel free to ask me for explanations of details. I might have the time/energy for this, so I'll let you know if I stumble into anything soon. I think a CHICKEN-specific implementation probably wants to use the FFI since fixnums are guaranteed in their representation: <https://wiki.call-cc.org/man/5/Data%20representation#immediate-objects> It might also be a good idea to enforce SRFI-143's behaviour around overflow / underflow as part of CHICKEN's default behaviour in CHICKEN 6, but I don't really know how I would get started having that discussion. In any case, I've cc'd Diego (SRFI-143 maintainer), maybe together we can find a way to improve the situation :) Regards, -- Jeremy Steward
Generalized-Arrays egg v1.0.1
Hi all! After about ~6 months of work, I've finally rewritten the generalized-arrays egg and am today releasing v1.0.1. You can find the repo at: <https://gitlab.com/ThatGeoGuy/chicken-generalized-arrays> I learned a lot from this rewrite, but here's a few highlights: 1. The egg is MUCH faster now, thanks to generous use of chicken-profile and the statistical profiler. I've left -d2 on the egg so that others can profile as well. 2. The egg now heavily relies on my transducers egg. This is intentional, and is part of why the egg was able to be made so much faster than it previously was. While one could use generalized-arrays without transducers, it is certainly easier to leverage transducers as much as possible. 3. The egg now has tests and even runs these tests in GitLab CI. Previously, this was not true, and many APIs were just broken or incoherent in ways. 4. Every API is documented and has examples to demonstrate how to use it. 5. The library is now an R7RS library. The main dependencies that aren't R7RS (that are used) are read-syntax extensions, as well as the check-errors egg. Likewise, I opt to use (chicken fixnum) but this is because I discovered that SRFI-143 is so egregiously slower than (chicken fixnum) that it was causing serious performance regressions in many of the array APIs. There were a ton of smaller lessons about CHICKEN, profiling, and thinking about array APIs in general in there as well; however, I might save those for a future blog post. In any case, if you've used this egg at any point in the past and been disappointed, I hope you'll give it a second chance. I've even added some cool examples of how to use this with BLAS in the docs. ~~~ A note to Mario: since this was a rewrite, I reran test-new-egg and noticed that my URI in the release-info file was wrong. This was probably some artefact of GitLab changing their URI scheme, but it should be working now (I have run this with test-new-egg). Beyond that, the egg is now CHICKEN-5 only. If it's possible, can we cut CHICKEN-4 support from 1.0.0 onwards? If not, let's cut out CHICKEN-4 support entirely, since pre-1.0 versions of this egg should probably not be used, ever. ~~~ Thanks, and happy hacking! I hope this provides a better arrays API than I had previously shipped. I am definitely more proud of my egg now. -- Jeremy Steward
Transducers v0.4.0 - Mappings
Hello CHICKEN users, I've just released Transducers v0.4.0. This adds support for using transducers with SRFI-146 mappings / hashmaps. See the CHANGELOG: <https://gitlab.com/ThatGeoGuy/chicken-transducers/-/blob/main/CHANGELOG.md> As always, let me know if you find any interesting uses for the library or have any requests for how to support your own datatypes with the library. I think my next big focus will be away from this library for a bit, outside of maybe writing more documentation / tutorials. Cheers, -- Jeremy Steward
Re: Transducers v0.3.0 - R7RS edition
Hey Damian, I must have missed this message when I announced v0.3.0. On 4/3/23 00:08, Damien Mattei wrote: Hello, does this transducers implementation add some significant speed to code when using them? i ask the question because i used transducers with Guile with very poor speed improvement compared to normal code. This question is going to be difficult to answer in any meaningful way. For starters, I'll assume you're using SRFI 171 with Guile? Relative to the SRFI-171 base implementation, I'm not sure that the transducers library I've written is ever going to be "faster" than a hand-written / hand-optimized loop. I assume this is what you mean by "normal code." I believe SRFI 42 can be significantly faster, but is considerably different in terms of both purpose and implementation. Nevertheless, I think there's a problem with the way the question is posed. Some thoughts: - "normal code" is ill-defined here, and I think it's counter-intuitive to think about libraries relative to code with zero abstractions in terms of performance alone, especially in Scheme. Generally speaking, I'd say that if you can get good performance with what code you have and you don't see a maintenance problem, then maybe an abstraction isn't necessary. - Asking about SRFI-171 in Guile relative to transducers in CHICKEN seems like it has a bunch of problems on its own. CHICKEN can generally be faster than many Scheme implementations but there's a wide number of reasons that code on Guile may perform worse or better. - You've provided no real indication of what you were doing. It would be difficult to say how transducers might help improve (or not improve) performance for some nebulous set of problems. Anyways, this is not to lambast you for the question -- I'm sure it comes from a genuine place. I'd encourage you to try the library out and use CHICKEN's profiler (call your application with the argument "-:p" without quotes, see <https://wiki.call-cc.org/man/5/Using%20the%20compiler#runtime-options>). It's often better to measure what you can and then make a decision from there. I'd also encourage you to read the documentation for transducers if you haven't already - it should give you an idea of what is being done and what kind of performance to expect (<https://wiki.call-cc.org/eggref/5/transducers>). -- Jeremy Steward
Transducers v0.3.0 - R7RS edition
Hey all, Just wanted to ping the list to tell you all that Transducers v0.3.0 should soon be available. This version won't mean much if you're already using the transducers egg in your code anywhere, because the main change is that I've transitioned the egg into an R7RS module. See: <https://gitlab.com/ThatGeoGuy/chicken-transducers> I haven't made this compatible with any other Scheme implementation yet, but if others want to upstream a patch to do so I'd be more than happy to review & accept it. :) For now I'll leave the project name as `chicken-transducers` since that is part of the URL for the release-info file, but know that it is a full R7RS library and that it should be pretty easy to port as long as you have a few SRFIs available (srfi-1, srfi-133, srfi-143, srfi-160). Looking into other active issues (<https://gitlab.com/ThatGeoGuy/chicken-transducers/-/issues>), I think I'll start seriously aiming to support transducers across more data types. I'd appreciate any feedback on which common Scheme eggs / data types are most useful to folks. Otherwise, I'll keep hacking away. :) -- Jeremy Steward
Re: New egg: CHICKEN Transducers
On 1/11/23 16:20, Tomas Hlavaty wrote: Hi Jeremy, thank you for interesting reading. Thank you for taking the time to go through it :) On Wed 04 Jan 2023 at 18:48, Jeremy Steward wrote: <https://www.thatgeoguy.ca/blog/2023/01/04/reflections-on-transducers/> My main problem with generators and accumulators is that they basically replace all our existing data types with a new type (generators) that can then be mapped / filtered over in a unified way. After one is done with gmap / gfilter / etc. they can then convert this generator back into some kind of type using an accumulator or one of the built in generator->type procedures. This solves a problem of abstraction by routing around it. Rather than worry about what operations are defined on a type, we instead just create a type that has all operations work on it. What are the procedures reduced? and unwrap in your example? Don't they point to similar issue with transducers? |reduced?| is a predicate that checks if a value has been wrapped by |make-reduced|. |unwrap| unwraps a value that has been wrapped by |make-reduced|. A "reduced" value isn't particularly special, but it's using a unique record type (and predicate) to identify a particular kind of value. This is how early termination is done with transducers. We could use call/cc, but that would involve injecting call/cc somehow through all the transducers / collectors / etc. Instead, if a transducer (e.g. |take|) wants to stop folding over the collection early, it can just wrap the current result in |make-reduced| which will tell the folder "hey, I'm fully reduced" and the folder will stop. It doesn't really point to the same problem. See, transducers are still monomorphized to the specific type. There is no polymorphism in transducers as the library currently exists. So there's no type deflection going on here. This kind of approach is a good first abstraction, but fails because it is generally impossible to make this fast. It also doesn’t solve the fact that we have type->list and list->type proliferation. If anything, it makes it worse because most libraries are not generator-aware, and writing generators correctly can be tricky. That’s not to say writing any code cannot be tricky, but the obvious ways to write a generator are often using make-coroutine-generator which uses call/cc4 and as a result is pretty slow on most Schemes. It seem that the problem is with the way people write generators in scheme. Not that generators are "generally impossible to make fast". Generators are "generally impossible to make fast." If you accept a generator as an argument to a procedure, then you don't know (from within that procedure) if that generator produced values directly or is the result of several layers of (gmap ... (gmap ... (gmap ... generator))). Note this isn't true of lists and vectors and other collection types: getting a value from a vector is O(1), and getting all values sequentially is O(n). Because of that, you can very quickly end up with generators that call generators that call generators that call generators and so on. This isn't inherently slow, but those functions aren't local and it's a lot more expensive than a simple fold / named-let over the data. Now, for a lot of code that may not be a problem. You might keep things simple or only use generators that directly generate values and aren't chained through several intermediate processes / mappers like above. Alternatively, you might find that a generator is doing something expensive anyways, like a network call. In such cases, maybe the difference between transducers vs. higher-order generator functions don't matter. For me though, I don't really want to work off that assumption. Transducers are plenty fast and there's not really the same issue of non-locality of the data / functions that one has with generators. The general advice of "benchmark your code and target performance improvements" applies, but if I write a function that accepts a generator, I'd like to be able to guess at what I'm dealing with. Fun experiment: for any given set of procedures over a generator I'd wager that transducers will probably be faster. You can test this yourself: (transduce reader-fold (compose ;; All variants of map / filter / etc ) collect-list generator) I am willing to bet this will be faster than almost any combination of gmap / gfilter / etc. I say almost because I know if your generator is doing a lot of IO or some kind of expensive network call then the differences will be completely dwarfed. So in the most general case, I'd say yeah - generators are pretty much impossible to make fast. Compared to iterating over a list or vector, I can't know upfron
Re: New egg: CHICKEN Transducers
nd streams sub-modules and write whatever extension you wanted extant to that. This to me is why I came to settle on transducers in the first place - it allows this extension without requiring it in the core library itself. ;) You actually do reference this later in your reply, but I wanted to underscore it here. It's an important point! By implementing iterator-fold and the type->iterator functions everything works OOB with the transducers egg. With some small changes to the egg[0] (especially [1]), it can be improved (IMO) to this: So I looked at the changes required here - regardless of the point on collect & sentinel vs. (collect #!optional sentinel), I am unsure that I want to change |transduce| too much. I think the transduce you've provided, i.e.: (define (transduce folder xform collector iterable . iterables) (let* ((xf (xform collector)) (sentinel (collector)) (result (if (null? iterables) (folder xf sentinel iterable) (apply folder xf sentinel (cons iterable iterables) (xf result))) is probably better implemented as syntax (to avoid the apply, as was mentioned in the TODO comment), and probably best to call |transduce*|. That section for (if (null? iterables) ...) can easily distinguish between single collection and multi-collection variants, assuming they all use the same folder. From an API perspective that to me seems more uniform / less special-case-y. I have to experiment with this though, because I'm biased towards believing that such code isn't really worth the extra complexity. With |chain| and |zip| transducers being available I think you can accomplish this in a more generic way (not requiring that all collections have the same folder), and I seldom find myself writing code where I need to collate / work across multiple collections. I know Scheme is dynamic and that enables this, but 99% of my code will always tend towards using a single collection kind. In CHICKEN's type terminology, that's usually (list-of T) or (vector-of T). The example of: (transduce iterator-fold (map (cute apply * <>)) (collect-list) (iterator-zip (list->iterator '(0 1 2 3 4)) (vector->iterator #(5 6 7 8 9)) (range->iterator 5 ;=> (0 6 28 72 144) seems a bit strange to me. I cannot rightly remember a time where I'd do something like this across a lot of types. Even thinking of code I've written in Rust -- it would be strange to do it this way. I struggle to think of a scenario where I'd have 3 different collection types that needed to be all zipped together like this. Enumeration is an obvious use-case, but |enumerate| is already a transducer. I'm not fully convinced that this code is what I'd steer people towards, but I do appreciate that you've gone through the trouble / learning process on this one though. It has definitely helped me think about it more deeply. I still have to give it more consideration but there may be something here for a future version of the library. [0]: https://git.sr.ht/~siiky/chicken-transducers/log/multiple-iterables [1]: https://git.sr.ht/~siiky/chicken-transducers/commit/68f9d6d3faaf80e1b57c7bda5dec888b34c670dd [2]: https://git.sr.ht/~siiky/experiments/tree/main/item/iterators/transducers-example.scm If it's alright with you, I will probably go ahead and grab at least the (test-exit) patch from above and apply it to transducers today. I can't believe I forgot that. PS: great work on the docs, Jeremy, they look very comprehensive! Thank you. This is probably the best compliment I could have received. Cheers, -- Jeremy Steward
Re: New egg: CHICKEN Transducers
On 1/5/23 09:45, Walter Lewis wrote: On 1/4/23 8:48 PM, Jeremy Steward wrote: And I've written a short blog post outlining some of my frustrations that led me to writing this egg: <https://www.thatgeoguy.ca/blog/2023/01/04/reflections-on-transducers/> Happy to engage with the rest of the community on what the next priority for such a library should be. Great post. I would love to see a portable R7RS library, which you mention as a possibility. For example, I am working on an R7RS containers library and it would be straightforward to include transducers as part of it. Excellent. I'll keep this on the radar then. I'll probably need to read (or perhaps if I choose to whip myself enough, write) a guide for what needs to happen to go from CHICKEN -> R7RS. I doubt it's too much, but I do use the check-errors egg so a portable shim is necessary, and I think I need whatever the fixnum SRFI is. Either way, I'll post here to the list if and when that is completed. Cheers, -- Jeremy Steward
Re: New egg: CHICKEN Transducers
On 1/5/23 05:49, siiky wrote: Awesomesauce, thanks for the egg and the post! This is a smnall-ish pain point of mine too. I'm still processing the post as well, but I can tell I'll start using this frequently! That's great to hear. I appreciate that you enjoyed the post and will start using transducers. First a couple of typos: In footnote 4 it should be `call/cc` and not `call-cc`? And "its not the Scheme I reach for" :p Oof. Thanks for doing the editing work for me. It should be updated now. About question (1) of "Some open problems ...": IMO (transduce type-fold ...) is a good compromise, and it seems better to me than (type-transduce ...) though it means a tiny bit more typing. My reasoning is that (intuitively, without having looked at an impl of either) type-fold is easier to implement than type-transduce, and thus it should also be easier for someone to extend the transducers egg with their own fold+collect rather than transduce+collect. An usecase of extending the transducers egg is e.g. if I have an egg where I define a data structure foo and would like users of my egg to use transducers on (with?) foo, but without having to change the transducers egg itself. Indeed, and this has been the reasoning in why I have left it for the most part. An egg like this is nothing if it cannot be extended easily. Noticing the distinction between implementing fold, collect, or some entire abstraction that tries to do both was something I realized about halfway through writing it (specifically, when I started adding fold / collect procedures outside of the list variants). There is always the possibility to use the wrong fold with the wrong datatype or some-such, but there's really no way for me to get around that without a full object system and types, so ¯\_(ツ)_/¯ Regarding (4) and strings: if we survived without transducers until now, I think can survive until transducers for strings until C6 too and use string->list+list-fold :) (I'm assuming UTF-8 will only become core in C6, maybe I'm wrong) If there were enough of a strong signal to just go UTF-8 only I'd probably just do that. The problem is that transduction happens on an item-by-item basis and I'm not sure that any string-fold will work the way you expect it to. In my experience you don't want individual unicode code-points, you want the full character. I guess if I had a special transducer (similar to chunks or chunks-exact) and a collector to take individual code-points and generate a full grapheme, then I could get something that approximates useful unicode transducers. But as it stands, I think anything regarding strings is going to be hairy and icky, because locales suck and internationalization means that any string logic will always be (somewhat) fragile. My kingdom for a day in which users can use strings in any locale as easily as some of us abuse ASCII. Small nitpick comment: I think it makes more sense to have either type-fold+type-collect or fold-type+collect-type. It's more common in Scheme to name type-operation so I'd give preference to that, but the other is more natural and equally good IMO. I figured this criticism would come up. My thinking was that keeping collectors prefixed with `collect-` helps autocomplete and gives you an interesting symmetry: (transduce list-fold (compose ...) collect-vector (list ...)) Notice how you start with list- on the left and -vector on the right? The transducer is in the middle and so you have list-transducer-vector if you squint at it hard enough. But that said: I'm completely willing to change that if I get enough people telling me they get it backwards and it's incoherent. Ping me so I can keep a count of how many times / how many individuals this trips up. Regards, and thanks again for the comments, I really appreciate the feedback. -- Jeremy Steward
Re: New egg: CHICKEN Transducers
On 1/5/23 06:11, siiky wrote: There are some things I would still use SRFI 42 for, at least for now that I'm new to transducers. For example: (list-ec (:list x lst1) (:list y lst2) (if (even? (* x y))) (cons x y)) Which is similar to (filter even (map * lst1 lst2)) but more performant because there's no intermediate list. I have no idea how to do this with transducers. I think the easiest way for this would be to just zip the list together: (transduce list-fold (compose (zip-list lst2) (filter (lambda (p) (even? (* (car p) (cdr p)) collect-list lst1) Thoughts? -- Jeremy Steward
Re: New egg: CHICKEN Transducers
On 1/5/23 04:22, Chris Brannon wrote: Jeremy Steward writes: And I've written a short blog post outlining some of my frustrations that led me to writing this egg: <https://www.thatgeoguy.ca/blog/2023/01/04/reflections-on-transducers/> That was a fantastic post. I'm still digesting it. How about SRFI 42? Here's your example from the transducer benchmark, written with SRFI 42: (import srfi-42) (time (fold-ec 0 (:range x 1) (if (odd? x)) (* x 3) +)) Thank you as well for the kind words. I am glad you enjoyed reading it. You are not the first to bring up SRFI-42! There was someone on Mastodon earlier who made a similar point. I don't think it's a bad library, but it seemed to have a handful of things going against it: 1. Locked in stone: same argument for SRFI-171 really, although SRFI-42 is a lot older and more battle-tested. 2. Macro-based: This makes it pretty difficult to extend, especially if you don't have a clear "standard" or "winning" data structure that the community can rely on. Not that it's impossible, but I'd have an easier time as a user writing a custom fold procedure (and maybe a collect?) and working with transducers than extending eager comprehension macros to support new types. A corollary to that: transducers are a bit more general because they separate the collection from the primary form (transduce, or fold-ec in your example). This isn't really a strong argument to dismiss it though. 3. Aesthetics: related to syntax / macro based solutions, I have strongly religious (read that as: entirely subjective) reasons to prefer to keep my Scheme code mostly syntax free. Transducers are a bit more "functional programming" in some ways (we still use set! though?), which is acceptable to me. To put it in perspective: if the SRFI community said "we're not writing new fold operations, no more (f k x) nonsense, and everyone has to learn SRFI-42 or write their procedures in their own Scheme modules" I'd probably still find that acceptable. The thing is that eager comprehensions aren't really pointed out or taught or talked about really all that often, especially with regards to newbies learning the language, or to try and guide "best practices" in Scheme. Of course, we don't want to tell people too much how to program, but I think encouraging code that is more performant or easier to "fix" (or debug) when things go wrong is probably better than not. So if I had to decide between transducers and SRFI-42, I'd be sad because both work well. But I'm happy that we can choose either. I just have a stronger preference for the transducers approach (and |collect-vector| variants are extremely underrated relative to how useful I believe they are). And here is a comparison of performance characteristics: Script started on 2023-01-05 03:14:57-08:00 [TERM="screen.linux" TTY="/dev/pts/4" COLUMNS="80" LINES="30"] $ ./transducer-bench 12.278s CPU time, 0.002s GC time (major), 1/108400 GCs (major/minor), maximum live heap: 879.61 KiB $ ./srfi-42-bench 3.5s CPU time, 0/70231 GCs (major/minor), maximum live heap: 478.02 KiB $ exit Oof, I'm surprised to see such a differential. On my machine it's still faster, but it's: transducers: 3.540s srfi-42: 1.623s Still though, looks like I have my work cut out for me. -- Jeremy Steward
Re: New egg: CHICKEN Transducers
On 1/5/23 00:44, Peter Bex wrote: And I've written a short blog post outlining some of my frustrations that led me to writing this egg: <https://www.thatgeoguy.ca/blog/2023/01/04/reflections-on-transducers/> Excellent observations, especially regarding the fold argument inconsistency, that's so cringeworthy it isn't even funny. I thoroughly enjoyed reading the post. Even if it's critical of Scheme, it's done in a loving way, as you mention ;) I also agree with you that SRFI has probably had its best time. Thanks for the kind words, I do hope it is recognized that what I am saying in the post is with love for Scheme. The fold thing gets me every time in every language I ever work in, so it was somewhat cathartic to write that down. Happy to engage with the rest of the community on what the next priority for such a library should be. My hope is that this library helps us all move away from XXX-map and XXX-filter procedures for each individual type. Well, like I said I kinda prefer having the type-specific procedures. I rarely deal with situations where I don't know the type on which I'm operating. I usually treat generic code with suspicion, as it's not going to be as fast as it could be, and higher-order code tends to be more difficult to follow than necessary. Well, the final transducers produced /are/ type-specific. The input and output types are parameterized by the folder and collector, respectively. This is a bit different than Clojure where protocols are used to paper over the types entirely. E.g. (transduce list-fold (map add1) (collect-vector) (list 1 2 3)) You will get a type error here from |list-fold| if you pass in a vector in place of a list in the last position, for example. Likewise, |collect-vector| can only ever collect a vector, and how fast it is depends on the size & number of re-allocations (hence why it collects in amortized O(1) time, and has an optional size-hint). I tried my best to avoid any of the higher-level performance pitfalls that would come about with transducers. Of course, this doesn't mean bad code can't be subbed in, but this is a library with versions and an issue tracker and a repo, not just a spec. :) I fully welcome anybody to tell me how to make things more performant or easier to debug if there's good ideas lying around. You are right though that higher-order code does tend towards being more difficult to follow. My hope is that as long as the parameterizations in transducers (as they currently exist) remain explicit that this can be mostly avoided. However, transducers offer one thing that the type-specific procedures do not - pipelining without accumulating lots of intermediate results. For me that's the killer feature of transducers. Yes, the ability to avoid intermediates is perhaps the main advantage. I also think that the fact that collection is distinct from folding and transducing is a separate advantage -- e.g. if you know that you need a vector at the end there's no need to worry about whether that aligns with the input / processing steps. Regards, and thanks again for the thoughtful reply, -- Jeremy Steward
New egg: CHICKEN Transducers
Hey all, I've been somewhat bothered by the fragmentation in a certain aspect of Scheme / Lisp: notably that there isn't really something akin to Rust's Iterator trait in Scheme, and as a result working across various collections and data types is a pain. So I introduce to you - Transducers! These are very similar to Clojure's transducers, but add one more parameter: a fold procedure. I was unhappy with SRFI-158 (Generators & Accumulators) and also unhappy with SRFI-171 (mostly because of how sparse the API is). test-new-egg passes with the following release-info: <https://gitlab.com/ThatGeoGuy/chicken-transducers/-/raw/main/transducers.release-info> I've already added extensive documentation to the wiki page: <https://wiki.call-cc.org/eggref/5/transducers> And I've written a short blog post outlining some of my frustrations that led me to writing this egg: <https://www.thatgeoguy.ca/blog/2023/01/04/reflections-on-transducers/> Happy to engage with the rest of the community on what the next priority for such a library should be. My hope is that this library helps us all move away from XXX-map and XXX-filter procedures for each individual type. First things first: I'll probably keep trying to add more common data type support (SRFI 146 mappings and SRFI 69 hash-tables come to mind) as I can. Let me know if you find this useful! Cheers, -- Jeremy Steward
Re: generalized-arrays egg, array-read fails on array written with array-write
Hey Matt, author here: On 12/15/22 10:28, Matt Welland wrote: This seems like a bug (unless I'm missing something?): (module justtesting * (import scheme chicken.base generalized-arrays storage-classes) (define (testit) (let* ((size (vector 100 100)) (ary (make-array vector-storage-class size 0))) (with-output-to-file "testarray.dat" (lambda () (array-write ary))) (print "wrote array to testarray.dat") (let* ((readdata (with-input-from-file "testarray.dat" array-read))) (print "read data into readdata: "readdata (testit)) OUTPUT: wrote array to testarray.dat Error: Expected a char representing a digit.: #\# Call history: array-write-read.scm:1: ##sys#with-environment array-write-read.scm:1: ##sys#register-compiled-module array-write-read.scm:4: chicken.load#load-extension array-write-read.scm:4: chicken.load#load-extension array-write-read.scm:34: testit array-write-read.scm:23: generalized-arrays#make-array array-write-read.scm:24: scheme#with-output-to-file array-write-read.scm:27: generalized-arrays#array-write array-write-read.scm:28: chicken.base#print array-write-read.scm:29: scheme#with-input-from-file <-- Is this with CHICKEN 4, or 5, or both? I can test on my own but I want to be sure I get the environment right. I suspect it is a bug and you are indeed not mistaken, and I should probably take this egg down until I get time to do a proper v2.0 or whatever. For context for the list: there are at least two bugs I know of (this being one of them now) that exist within the library as it currently exists. The other is an indexing bug in array-fold I believe, but I need to go back and check. Once upon a time I undertook a redesign of the underlying API to evaluate different ways to work with indices so as to: 1. Provide faster iteration AND 2. Improve clarity / correctness of the code But ended up never finishing that work. I do still want to fix this and make it useful, but I haven't been as active in the CHICKEN community in the past couple years, mostly due to being too engrossed with work. I appreciate the bug report though. Is there a ticket on <https://bugs.call-cc.org>? I believe the official repo is now on GitLab <https://gitlab.com/ThatGeoGuy/chicken-generalized-arrays>, but I can throw an issue up and think about better ways to solve this. Since writing this egg many years ago I've implemented various array / math libraries and now think I have a better appreciation for how to do it better. I really just need to make time for it, and I've not done a great job here. In the meanwhile, I'm happy to collect any other bug reports or test cases. Either in the above repo or the CHICKEN bug tracker are fine, I keep notifications on both and try to remain active on the list even if I'm not being as good a maintainer in other ways. Cheers, -- Jeremy Steward
Re: New C5 egg: SRFI-145: Assumptions
>> SRFI-121 is only in the C4 coop and likewise SRFI-158 only in the C5 >> one, so I don't see any need for removal. A deprecation notice could >be >> added for SRFI-121 to the C4 wiki page. If you insist you could add >a >> stub C5 wiki page pointing out the existence of SRFI-158, much like >it >> was done with readline/breadline: >https://wiki.call-cc.org/eggref/5/readline Actually, CHICKEN 5 support for SRFI 121 was added earlier this year, so it should be in the coop? >Second, I think it's a good idea for Chicken to have more eggs rather >than less because some people may look at the list of libraries or >supported >SRFIs as one of their considerations when choosing which language to >use, >so it just looks good for Chicken to have more eggs, when looked at >from >comparison tables like these: I would disagree, in that sometimes less is more. SRFI names are baroque and hard to parse in the first place, and presenting a (mostly false) choice to users can create confusion and anxiety. I am completely on board with updating the 121 docs to point to 158 over completely removing it from the coop, though, so as not to yank the library out from anyone who may currently be using it (and doesn't want a harsh transition). I guess in essence, I don't want to pull a leftpad.js :-) -- Jeremy Steward
Re: New C5 egg: SRFI-145: Assumptions
Ooh boy, is SRFI 158 ready to go? If that's the case, should we deprecate / remove SRFI 121 from the coop? I am currently the maintainer, but am happy to focus efforts on 158 over 121. -- Jeremy Steward
[Chicken-users] Chicken 5 support for srfi-113
Hello again! Seems I also added chicken 5 support for srfi 113 (sets and bags) some time ago, and never bothered to add it to the coop. Can someone add this too? https://raw.githubusercontent.com/ThatGeoGuy/srfi-113/master/srfi-113.release-info Cheers, -- Jeremy Steward signature.asc Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Chicken 5 support for generalized-arrays egg
Hey all, Spent some time to update and add support for my generalized-arrays egg today. Find the release info file at: https://bitbucket.org/ThatGeoGuy/chicken-generalized-arrays/raw/master/generalized-arrays.release-info Since there isn't yet a salmonella for C5 I haven't been able to test with that, but this repo should be working if my tests today are any indication. Cheers, -- Jeremy Steward signature.asc Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] srfi-128 - almost
On 08/18/2018 06:12 AM, Jörg F. Wittenberger wrote: On Aug 18 2018, Jeremy Steward wrote: Hey Joerg, I'm the maintainer for that egg. I know; we talked about that before as I had packaged the same srfi under the name of "comparators" before. Ah, right. Now I remember :) I'd be happy to review the pull request, but just haven't had time. I can look it over tomorrow if necessary to get things merged in properly. I did not want to be pushy. It's just a nice example of a situation where I'd like to consult alternative sources than those baked into chicken-install. No worries, I needed to get on this (and several other eggs). I've reviewed the PR, and tested with both CHICKEN 4.12.0 and 5.0.0rc1, and it all seems to be in working order. I've merged the PR and we should be good to go. Couple of questions in general though: * How does updating the .release-info file work now, if you want to support CHICKEN 4 and 5 at the same time? * What do I need to do to add SRFI 128 to the coop? Regards, -- Jeremy Steward signature.asc Description: OpenPGP digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] srfi-128 - almost
Hey Joerg, I'm the maintainer for that egg. I'd be happy to review the pull request, but just haven't had time. I can look it over tomorrow if necessary to get things merged in properly. Regards, On August 17, 2018 11:44:17 AM MDT, "Jörg F. Wittenberger" wrote: >Let's try an example. > >I forked the srfi-128 repo here and ported it to chicken 5 >https://github.com/0-8-15/srfi-128 > >The .release-info still points upstream where the pull request went. > >This appears to install and work. > >Brings back the question: how would I tell chicken to temporarily >consult >other locations for egg distributions? E.g. I'd like to use >chicken-install >in a fresh location outside the source directory of the egg to check >that >the whole download picks the correct files and all of them. Or maybe I >just >want to install an egg I deem not good enough to release. > >Best > >/Jörg > > > > >___ >Chicken-users mailing list >Chicken-users@nongnu.org >https://lists.nongnu.org/mailman/listinfo/chicken-users -- Jeremy Steward signature.asc Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] New Egg: Generalized Arrays and Storage Classes
Hello everyone! I hope the weekend is going well! I'm sending a message to announce that a new egg is available: Generalized Arrays and Storage Classes. This egg provides a data type for generalized multidimensional array types, which are backed by a set of storage classes that define how objects are stored (and what types they may be). You can think of this as providing a set of procedures and data types that mirror APL, and to a lesser extent Numpy. Go ahead and give it a whirl, the docs are up at http://wiki.call-cc.org/eggref/4/generalized-arrays. Currently the egg is in somewhat of a beta state, and I currently have not written any tests for it. I plan to continue to write tests over the next while and hopefully gain some robustness as a result. I have continued to test while developing and think I've ironed out a good number of bugs, but any test contributions would be welcome. The easiest way to get started is: $ chicken-install -s generalized-arrays Please do let me know either through this mailing list or on IRC (DeeEff in #chicken on Freenode) if you notice anything missing or if something is wrong. My ultimate plan with this is to eventually integrate the arrays API with another high level interface that is powered by BLAS / LAPACK, opening CHICKEN up to a world of numerical libraries and / or scientific computing that hasn't been as possible up until now. If you'd be interested in helping me do this, I'd be happy to talk to you. Best regards, and Happy Scheming, -- Jeremy Steward signature.asc Description: OpenPGP digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [ANN] CHICKEN 4.12.0 release candidate 1 available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello all, I ran the following installation tests and got the following results: Operating system: Devuan (Debian) sid Hardware platform: i686, amd64 (x86_64) C Compiler: GCC 6.3.0 Installation works?: yes Tests work?: yes Installation of eggs works?: yes (readline, blas) Operating system: Windows 7 32-bit Hardware platform: i686 (virtualbox) C Compiler: GCC 6.1.0 from MinGW (no MSYS) Installation works?: yes Tests work?: yes Installation of eggs works?: yes (pastiche) Surprisingly, everything worked quite well compared to the last few times I tried installing on Windows 7. Even feathers installed correctly on Windows this time, whereas with 4.11.0 it would always fail somehow. Good job to whoever fixed this! Note that in the case of my Devuan / Debian installations I think that my version of readline is too new, and thus the readline egg may need to eventually be updated (rlwrap works well enough otherwise). I get the following error: ~readline: rl_catch_signals: unknown variable name I don't think this has to do with CHICKEN 4.12.0rc1, since I can recreate the issue on CHICKEN 4.11.0. Let me know if there's anything else I should try testing. - -- Jeremy Steward -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE+Uzd98zIxsQP1/ExAnWrBIob9/YFAliOmSwACgkQAnWrBIob 9/bSWg//dHh+54Wiqn10k167w5/T226wedLeTt6V0Apt3UtvBs6v9LVD0XbESfhY 6IAiMG5L9kgvWtrnr2s7B4DJm2ZQI7EOH4j4AebqNlyi6zjvIqXya6zYtG6RwWeB MMct63CRqbTqe1D3qJejBhoYcx12oUJmpd+n1Q+qQUsoLD0Nt9Tm3NooMMKPnk5d oxBDKOrJ+cv78PgIarzmG2X4/Jid6nfGZ3UlrFEW2Xr8JTkhxbLxgO6pye6fzrRu 1tA3CtuTIQhid86oBoNw/A3EIkzdOGBOSqQzlQzBd3u3FZuunFqmJkmJdcvskVez Ggr3q/BM05KSRJvAeJETnFBnbOrdLsqeVmSKFc4Fd2/scpsDe+C64qfxNXdc/um4 w3PJVlgjwYteoSuoduU6epgwTftt/togZ9EaqlVgbS2NDm1JTGjuEVLeSAr6YqRy 6nMyS3XKwP+kD514RUCaH/bOmetfh/4LNOyXPRzSUMJ81FLAQ3RBj+kBU6E6Ozxa c3xUw6Ey6NSjQkRWqgn9oyQT7u3nIf/x1UcQGidKBbxiGs+tDcXggUJ/xQUO9bo3 uq7vHvpUsXXdmU0HnPLC20ux0qWpjsg2tZZMrIDl0mV9rTZYm8cJcc0/I8uO9pAo C5KGG0zpb+0/66C1raUH3yU9KpCCa3WHJeVfCj5jdBuc4C0/tJ0= =GFdQ -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Switching over SRFI URLs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 To Mario or Peter or anyone who can edit henrietta-cache, After some talk with Arthur Gleckler, he decided that it would be best if the CHICKEN community maintained their own parallel fork of the SRFI repos, as the burden of updating the SRFI repos is too much when I have to bump the CHICKEN versions every time an errata is introduced or if he makes any changes to the README files. That said, I'm maintaining forks for SRFI 113, 116, 117, 121, 127, 128, and 133. In order to accommodate Arthur's request, I only had to point the release-info URLs to my repository (github.com/ThatGeoGuy) instead of to github.com/scheme-requests-for-implementation. So I've done just that. Could someone point henrietta-cache to the right release-info file? The URLs for the repositories can be found below: https://github.com/ThatGeoGuy/srfi-113 https://github.com/ThatGeoGuy/srfi-116 https://github.com/ThatGeoGuy/srfi-117 https://github.com/ThatGeoGuy/srfi-121 https://github.com/ThatGeoGuy/srfi-127 https://github.com/ThatGeoGuy/srfi-128 https://github.com/ThatGeoGuy/srfi-133 This should not affect anyone using these eggs, as this should just change the source where they are downloaded from. Cheers, - -- Jeremy Steward -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJXlnQLAAoJEKflx7ZMcbY7lLMQAIF75ctjxw58L1ozxYCV6l9a M6zX1/vBJOfwp5r0nUS1m/ujrmk7KzqrLVz66bWbJF/VvS3bbj37qKbQLG6TE4cC UpvGxlnVdAzilhGuPq9fX2rdR/w3zlxDO0YE6kqDJXrgMFClRuG3tb4bcufStcsL UCE+CIKRB+DnKQK3CeI2/flFx7btVFwIlZUdZ0DBoWMV2JTT03irFnWFUzVuVkgQ kQlX6HjVCreI9xMjrWGDdoU8Su56WMi3HOd6eC34h3Hm20yrpS01P6MQE3QppJZc GoKh/DySCM2yUO2o7BI5v79HL20O5Wk77tRR/gtFbq3X/qeWIo2EY8z6x2eEwHJl E3Qdv/j/AxbpaFEXBXLTYVq3IiTPldeXjYxKbMq/ojv0q3tJw5j2x5xj7O5eM+VL k5PmgTExMJPL+D35oshmc8R5ft9URWYIXNeN1CIZ7sDUSZc4MVbC9MgCYmODWyp8 s0G5tDAQ2UiB4LGw6em8EuLJMvoyMrIhJgL+R8SoXLQ0SL4gJkTES/OqyIqvJ6j6 CaEmlRCZZyvd83yDfRkA4tuVPcew0vUC89VfmF4XwvsNd8fk+kBTqsy/u59OmEiq YTCiaEP4fWGaDewr/2jKlmHU5vWpf4O2qSLD3eXXUgZetmOBMnNMztQNUz2/ZPWe CGMciVEuSI6E5bXY1/h2 =dC9B -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New Eggs: SRFI-121, SRFI-127, SRFI-133
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/24/2016 05:59 AM, Peter Bex wrote: | On Sun, Jul 24, 2016 at 01:28:25PM +0200, Mario Domenech Goulart | wrote: Hi Jeremy, | |> The repositories can be found below: |> |> https://github.com/scheme-requests-for-implementation/srfi-121 |> https://github.com/scheme-requests-for-implementation/srfi-127 | | Installation of srfi-127 fails because "lseqs/lseqs-impl.scm" is | referenced but it is not in the list of files to be fetched (it is | in the repository, but not listed in .meta's `files'). | | Error: (open-input-file) cannot open file - No such file or | directory: "lseqs/lseqs-impl.scm" Ah! Curses, this was the third one I did yesterday, so I can see why I messed it up. I fixed the typo in .meta and submitted a PR to the repo. If you try again in a few hours (maybe tomorrow at latest) I suspect it will have been merged and the egg can be added successfully. | Generally speaking, I would avoid using "meta-file" as a | distribution mechanism, precisely for this reason: it's too easy to | forget adding particular files. The targz distribution method | works fine with GitHub. Well, yes. I originally packaged SRFI 116/117/113/128 using the targz method, but the SRFI editors add some extraneous files to the repository (strangely enough, a targz of the entire repo is... in the repo). In any case, rather than have users download a few extra MB of extra files, I think this works better. | We talked on IRC about using meta-file, but that was in an attempt | to avoid forking the upstream eggs, but that didn't work out. I do recall some discussion along these lines. However, here it's not to avoid forking, but rather to avoid downloading files that might pertain to other scheme distributions or may be unnecessary to provide through `chicken-install` (the targz in the repo as the prime example). - -- Jeremy Steward -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJXlNxYAAoJEKflx7ZMcbY7CbAP/AqXypXOord2IQqar3IgFbbG UL+huDfVAGVgMEwphmckCyV/xmskTgdZFckymlp2VWmo7At8zCVsJjaDkTEQRIl9 4fXNAhttAGG4LT1KGyRJ894Up2kApEJulefZha2M8PpZMwpoOR/baHVtf6efeSHe 4oBE1RRi5As1nu/dmLfxN3W88swhxKsSKSeqfGabppYvhAjV9x7v/8/Bah4iYVgF IkxFAxksUWyxCxuK+KOVn1qQlcwAny+mo2PMrW6jTLHtNhGKe26KRL39WHS0DAm9 eiluHe5/uLCvJrzD9XwA7d3TA9BilXIwxtCsQfB1u2q9IbOGITfPLetrKVcywMMk Yig45DHOnTWbaYjmO4YJmJb2tUsnTNkLXcnZVQKRP2q0GI0IJbLRtxKfDD6cwqaV XlzGpn3EsIe/s9odJXqWOmWbtQ221003nHefVOABkGQzPyTB6XLuupyqEvfxDKOf PvvE+ky33eoZVQbjBRhLkqkebBuc79xGQjltjJ1NM+DqoHns+wDy/0w9uOvhb51m dXG1uqiMFvibkFkwslezSDD3X+3tX5UK5N49Tc7RwEcsy2lEUTVpWFQ72srPFIjM IBPZinHs0ARqvXp8WkKFmB0AzdG3CigvteEQ6fLmi7BiUCCJZRUoi2fwX0ImsRhu 1t4rFWD1pZ2vp5i2ba2C =3SyJ -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] New Eggs: SRFI-121, SRFI-127, SRFI-133
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello all, I've taken the opportunity to package SRFI-121 (Generators), SRFI-127 (Lazy Sequences), and SRFI-133 (Vectors [R7RS-compatible]) for CHICKEN. The eggs all pass salmonella and shouldn't contain any errors. The repositories can be found below: https://github.com/scheme-requests-for-implementation/srfi-121 https://github.com/scheme-requests-for-implementation/srfi-127 https://github.com/scheme-requests-for-implementation/srfi-133 Thanks again to John Cowan, Arthur Gleckler, and the SRFI committee for the reference implementations of these libraries. For those who don't know, these three libraries were recently voted in to be included as part of R7RS-large. While I don't think that CHICKEN strives for R7RS-large compatibility, having these libraries working with CHICKEN is a pretty good step towards making R7RS compatibility a trivial effort. Cheers, and let me know if (when?) you find any bugs, either in the installation / setup or otherwise. - -- Jeremy Steward -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJXk9uvAAoJEKflx7ZMcbY7GCcP/3d3znISeSj/V6rOxTqQYamJ 7ElFkGwVfXYlI3AysBENPT2La4li2OYKEdRZPufxs7PCALBIWCX6DsmAGDKWvJZK 2FVpwYJ5ryooRBvl6lMt6wIOao8+69T4UDCaRYG9SkcHh8Y8q0h/TwHmKzqtHr0R w/totVBV32V6ESrnvgpx9KYEvdYEY6EpN2D7GQ2ncSuZZkMHi1CZq25JW6VlxPUG cCnvgLznULduf9unEvy/sN71kPLTTLiR6rEzJhX3kDgdnQlJx8VKkfaeyFGHqJX3 HKLtcCduIsiEXaJdh8AKHa0VxGMHLQZLnE7C2aoiDnMSXEXXQSH/6lgKZRb+Em4a ZvBTrFCuS2KYXxMoTB18jLK4pa++VsvK40CQS3CxaMywpa3ty2Y8iCN/+iUychfV /EqGDZI3I3Qy7tXcIfCrOEzmC8Ksrt0YmV6w3Mppa+yZXTM2NE4FhXGfj8p5kGZU u7azPsQZajRHpakUd+VauT0hHTdmLlBXXGbSKwQBsfBvCkdgOrl1seAyMfYIAQIE okskxuxtoNY3ZRG1a/uibMhQ+SeXxo5Jg8kLjfGakaM5XeutHrUXtHEtkNK6AcmJ Z52O6ctENBblt/2v0LUDQmyvFJkI0h7M6Xi1lczL85RKzS0xVlUb2rCPQJCvNUGy Fzjw2KSmEUoME8H1dzGT =kspH -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] generate numerical list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/07/16 08:57 PM, John Cowan wrote: | Jeremy Steward scripsit: | |> Note that iota annoyingly does not work well with the numbers egg |> -> | | This is a general problem with the numbers egg and all other | Chicken code, whether part of the main build or an egg. If the | code is not *compiled* with the numbers egg, it will not know | anything about ratios, bignums, or complex numbers. | You are indeed correct on this. I apologize if I made it seem otherwise, as IIRC you can get many things working with the numbers egg by using the following: ~$ csc -X numbers ... | Chicken 5 will have a full numeric tower natively and won't have | this problem. And thanks to Peter for this and many other great things. - -- Jeremy Steward -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJXhF2DAAoJEKflx7ZMcbY79B8P/RXzzHoHDkABY2hopNJfazXy BFQVXko9P2MkVjS1Idl796FVPZVa9HA5quKeJLGj7pX12OZ5hYcZx9GG7jLGrMQF dq07Eo/iswfHWZXobCEcfqu/P7tOzXbHqqgDtzZS50HX+WLpTuhM4+S/QP/x30Id vBmV3tj2/JDO8U0yWol/212tySV2DZ8iLi3iHuuLCX50fPXGcGIVVS7jU1vC2Dme 2lmZEmdT92BtV4htpT4e0CtRi/eaAWTRfxCksfbdVy3TEkXaAo9yUWvhL4tFFyMF A+Il3kG9tS76w20y+nIhhIjocegMBUVWLZSPHxJrihr6gWPUA6vwmCZwEMCIFsaA LYx22yG3PLrejD2LQMLBcE/x+gTEnsxEdXsSFnU3YV97LSaEST1cbAQOpMlRdnx+ dKOmc8Ym3eZ7Vsu9K4/h3Bgg74D14aVk5XzRS9VVt5+p3S+8LkmxXabYe/7H4irT R+Y5Hf72LcRAFAZ/5lT+GooucYyVF1xbrNoWdi4Y3j0bgYg98sL2M7jgVwApiSjr bd3hcWEJfpH3SuyB95R2mMsdHSrGwjBwpANvM0e5fuuT8kS+QeHv+gIUB4BkYuF4 uTuyaHv4ic6S9ZcLlKo0JHb4e9kis86jJqpsmvIfzUWDw8XN4hKL7iMadR5VMuEg LLEOI08pb2PqQEUvvC9i =uy7o -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] generate numerical list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Note that iota annoyingly does not work well with the numbers egg -> it cannot figure out what an exact rational should be. So: ~ (use srfi-1 numbers) ~ (iota 1 10 (/ 3 2)) outputs: ~ Error: (iota) bad argument type - not a number: 3/2 Instead, you could define your own `iota` procedure after importing the numbers egg using `unfold`, or you could define something like MATLAB's `linspace`: ~ (define (my-iota count #!optional (start 0) (step 1)) ~ (unfold (lambda (x) (>= (/ (- x start) step) count)) ~ (lambda (x) x) ~ (lambda (x) (+ x step)) ~ start)) ~ (define (linspace base limit n) ~ (unfold (lambda (x) (> x limit)) ~ (lambda (x) x) ~ (lambda (x) (+ x (/ (- limit base) ~ (- n 1 ~ base)) ~ (linspace 1 10 10) ;=> (1 2 3 4 5 6 7 8 9 10) ~ (linspace 0 50 5) ;=> (0 25/2 25 75/2 50) I'm sure I'm omitting some error checking in the above (for sequences that would end up infinite), but it should get you on the right track if you do find that SRFI-1 does not suffice when using exact rationals. Regards, On 11/07/16 08:21 PM, Evan Hanson wrote: | Hi Jinsong, | | SRFI-1 provides `iota' -- http://api.call-cc.org/doc/srfi-1/iota | | Cheers, | | Evan | | ___ Chicken-users | mailing list Chicken-users@nongnu.org | https://lists.nongnu.org/mailman/listinfo/chicken-users | - -- Jeremy Steward -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJXhFlbAAoJEKflx7ZMcbY7zIoQAJnzUGexanBT0TbCv+si8ikG jUdQUstCMWXK/IJNMRYuaavm/c76bYxtOlrsjgv6HfXoQ8z0+mj/lwduS3GkNdvG bL6QEWL5sgXIPmlbPWdATeslb/G+5zOVp2HygLhXoP92L5b2w+5Io5iWfBeJ9yUG Xn6J5uxGBjyS5TQoYDQeNaTyuIqebPPxhsgCeEdKBKBr6D1kbfrZHc9MmiGXhDhh jMpL/lQ7Wq3BcxUZYQe1MR4vn2sdm1p5tHtnAgI4xRylIyvRliSZiljMW8kwsB5S 6/TaLJSjJeo5TVTWtzdgI8LUbWPnYm1i021DKQPbqQzI0sSwTfFrbZgzFiIQzmL/ P4geRABA49TliHvwpUpf77DgC9U04O9bpoSM1Lzg3CTrQyANOOz5qj+S2MKLGcKU irJgGPI+rrbHqBBuUGUOV4Lgi/+QSycyZ/JxuJZMONyWf0MjjCl4TkqB34atLHzP xxrqe+hcronSYmz561xFNoUO3aaDtVo2gyG6eN9uEo/uH64N5Ob3B3Tw6fmQqNO2 bz1U6waurp3QDuUBYdGT1zGL0bm7MSAAGrGEi+ZBTvPRENLlh1zw8H3bSYT9uO6S LAQNs2GzvmREr7VuGqrceQ6C8K16B41gifo6rJGVByrr+JGlCfjFtGs5k6z0dbSo Ug6m2Fx3aWaOpnXjlmmI =36Ss -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Installing chicken on windows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Kashyap, Welcome to the mailing list! In my own experience, using CHICKEN through Cygwin has always been the best bet. I believe Cygwin has a package for CHICKEN, so installing it should be fairly easy. I've also managed to get CHICKEN to work quite well with Emacs (geiser) / vim (slimv) by adding the binaries for Cygwin to my user account's PATH in Windows. Have you tried installing using Cygwin whatsoever? Is there any particular reason why Cygwin would be undesirable for your purposes (aside from well, having to install it)? Let me know if something doesn't make sense :) - -- Jeremy Steward -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJXftJfAAoJEHVwwAZUeZnZ+CoP/1Kn/kLMuTZnQ8cWGbXBx51q uwl/4P8AIkFN2bhcEReb83yd0M6qWZBneSe2LwXheJ6rvBNhhRbh85c90oHI8iWE VkVkjiFMxMBEJWOwtyXCDxn2MA4wof9xXiA7cb0HzMgW5fcz2D2M659SmNZ9IxpX 7intglp4vIocwBY0X0x0QXQHLy+qXBUnGmDKhUdbvGjVAKIksx+8tcKW06jU0zbR bVmU/lUXeKfM6PKfpZkyCmsw67WnvoDY7l2RpyODi+MNzpbfYy/jTuePoPMlDf8Z C2Hil+SRpPAnHm9Z6udvLwDWVQHImkkkVvvOVG5QOztqJWWnsATdbwTtoQI/HDYk YSzVEvBwrHPe/rrkFdBOiUJqoTNkudiYkWwve7Hk1W+PrRtQzEnVS+lgLrIVLc3/ lwbochf1sK3kKvCNJIFQpXT2hP7qSpqfmTjxKEOkJNv7Z+ekNGgFYu7IpjD8A8gs URkg1qT+ZfKNnm0XKJplREbgV8QfqpqkYowbKKd+Qg3ogRqMiU7/+nk/2XDuopYa QJaaQefBD6Mfh3GfHEqO5EiwZNBD2VmjDgOxSf34C66VppNouiYfFYPh5jvguXha 4/jwSojxfUTJRiJkPCOOMwvXxmokwNvPQTUkwv2zTo9W3SfG9YDYItocmhMFjgtF C/1kZfGhPU7Mqn8WlwQ5 =a1lw -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New Eggs: SRFI-113 and SRFI-128
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/05/16 11:06 PM, Mario Domenech Goulart wrote: | Hello Jeremy, ... | | Some comments on the packaging: | | * (version ...) in .meta files is not used by chicken-install. | Only the form in .setup is used. I'd suggest removing (version | ...) from .meta, otherwise people may start copy'ing it, and | we'll end up having one more file to update in case of version | update (or one more place with inconsistent information, in case it | is not properly update). Duly noted. I didn't think it was used, as I've never written it in meta before; however, when I packaged SRFI-128 there was a version tag in the meta file that already existed in the repo. In the future I will not use them, in this case I opted to leave it as I did not want to change too many things. | | * instead of (author "foo, egg by bar"), you can use (author | "foo") (maintainer "bar") This is interesting to know. I'll put it on the roadmap for future versions. I can update them quite easily, however to actually put the tag on Github requires me to message Arthur Gleckler (maintainer of the scheme-requests-for-implementation account on Github), and ask him to throw new versions up. | | * Why do we have a tarball into the git repository? | I do not know. You could do the same thing with a git tag, but for some reason all the SRFIs on Github do this (so I presume there are hysterical raisins of some kind behind this, potentially due to mirrors that don't use git). I didn't include the tarball into the meta file, so it shouldn't impact the egg. Thanks Mario. - -- Jeremy Steward -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJXKDZAAAoJEHVwwAZUeZnZ+54P/1G7KwvjWDoGE0287AYipadh odtALHdS2FufEWmNS4Wuxx+0NGBbJyyQyRfqT2yco9lnytRE3BtXQYUxNeOrXf2p 1+3L7exUv/T2nKo+yrditj3liMXCl89FQqQCgzWsOQ8Y9KYw34Dpy0Ptfw29dKeu Mr2KlErSkNOrh9d5q7FgOG3sExHJkBXy913QixzbEI5JQmGBDHifhdvP2ofDZ3mc 3VOr9HIJlgljKZUefcmXJ6JgiLy489rQ0SioNlg+w3xPSouUrdnu7v62tkdRPn0t I+glObs1Fzn5GiYfFOyb+YFeTcupcK78gbUWopDk6Gcc61EApWQyfGjvbpDPhwh7 8CXWCmt6HfWzOqf3IjJIRpPodouM9CbfMxJ8C/HtUph3GpU3+bONkOu/j5lrYI/m wkPBvODBP0if78cLV3iuWKPHQWBn86kYyD78bahHuDukpKTjw2DscuSU8+YmecNz xNKCS5qZ1iQ2BiFRcfAEq1b7+nMrIeuVtgqpl6MMVziA3eoUpCjf3bb76+CVjBmy 2HEJ8mD8Wm5ZyTjGW9+ZD/ETtipmlGCCABMVR0jG5BPT3Fj/PxEbtTNaVHKgbowR xIAvvbpqQ3VrHUOgPyCCkbJLcROvl2nCcKNNdE35akND9hYF6jAwVX/4Cmn9GAUd BH6Atb30EIieA2QCA2fz =R9SO -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] New Eggs: SRFI-113 and SRFI-128
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, Over the weekend I've taken John Cowan's work on SRFI-113 (Sets and Bags) and SRFI-128 (Comparators (reduced)) and packaged them up nicely into eggs. The URLs are below, I think it'd be great if we could add them to the coop. Salmonella reports all tests passing and installation working correctly, with one caveat: Since SRFI-113 depends on SRFI-128, I cannot yet run Salmonella independently on SRFI-113, however I expect there to be no errors. https://github.com/scheme-requests-for-implementation/srfi-113 https://github.com/scheme-requests-for-implementation/srfi-128 I plan to package SRFI-133 (Vector Library (R7RS-compatible)), SRFI-121 (Generators), and SRFI-127 (Lazy Sequences) as time permits over the next couple of weeks. Any feedback into which (if any) new SRFI's that haven't been packaged for CHICKEN are desired would be great, so I can focus on those additionally, provided the work isn't too severe. Best regards, and thanks again to the work that John Cowan, Arthur Gleckler, and the SRFI committee has put in to make these libraries possible. - -- Jeremy Steward -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJXKCr3AAoJEHVwwAZUeZnZJRIP/R8ftcRC595P6uZY4rIqWdUc gGHx093YcCaKFZNkflAtQs8KoSZZQVBw5ZsfZ9q/r+/P2CvsHtlzy+bAIe8agMP8 YtNFxyQgNKtHfaDPw0YRLiJOZOJlQWAO4Kdo6mOLI4cxrZH+PPs765UdpC37NDNp 57zdnKfS+vvg/LiNKPVeAvQHKOSoCRObiwdnvWA6yQLYMsWjQoIqFMDYAUvwr2YA luJlY0QaH1CDmGhYs3NdthUo8Lehx4k3Isw9bAJlxr/IQzortxZLuVHsrSbGbKAY rzYiOgblZtkdQTOB4sBeYRe3U157Lq32EsysLWsIL22FcJjSFIC2bw/cGZZ0HWNr eZ9WEm8++1a9jjIFmBZConE8zETEn4YdJoIbva6pX1XDlHhbw910PGEZJ7OyBvxw 274MMV69gbZgcm1qClhu81vtL+xIGkDWYYoy+iIVX7EvEKiJf67M5jfBECItzeQN m7SiJxnGwX++dYLZK5tvZsrABJ0w/M3NjyrDFOXMvqNIzJxFAMthqsJYcPAa7k7e d1N4/i45Az42xrZGtumUOKL9WhvE859tXQwPI6fk7wI6bEUbkyQqeeE5U/nWMcj4 Y8Ij3xI/6ftXJZFXC1+8RrAgAxBPCFyp8vHELuntvqSFNfXHB8LCYjGtMObG2TaP 3cYN0uuWMGzXJj74ElBg =6Qog -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [ANN] CHICKEN 4.11.0 release candidate 2 available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello all, tested and verified the following: Operating system: Debian Sid (unstable) Hardware platform: x86 (Debian i686) C Compiler: gcc version 5.3.1 20160424 (Debian 5.3.1-16) Installation works?: yes Tests work?: yes Installation of eggs works?: yes The following eggs were tested for installation: * arrays * matchable * lazy-seq * coops * bind * graphs * utf8 * numbers * readline * hahn * slime * chicken-doc * apropos * make * mini-kanren * fmt * format - -- Jeremy Steward -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJXIoTZAAoJEHVwwAZUeZnZaPEP/ii+Jjivp2l88/xwodSzwGCT NqPHGLk8NMcPo2Rh19WvCH4GcYEYBhwIuBmBZH/EyQZLCfzL1FGpJ/2xzzHSCLEL ZI7gGxeVMWykA/7SD79Qeoz4rYN/401uqSf5ogbFOBdEgA0JSTiakIXPaa9atC1Z 8qljoqfpYxTLF5NC8+5Gh1VFFq8Kacgp5szl0/c4Pua7ZFMDKd/ZXtgrd7XldQgR y3OHyXh8lIBgJ7gNzCT3crl31HLQrsxauqnlD97jSgnWt4KbH/2NvqB+fsnJ+PBt KPgstzPFXChrFRPhNyMWvcpq1pZ4n0uRWlVgxengeJpehXQhDrQtpgdhM78bkR0x v7YohcBnZGy7+LX4GrPZ6Ry5xUzd+7/Nq8HJRu6S4blud96KYBE3P6xsWZ4nMrJu byNHYLgLvAQv+q+/CmwrzLxRYvA8VdNlBaxj4n5wQmhXlJvXcjM5VpYcnFWz7/Id XY6GX87ypNGwHRMdf8cU/l8tmzIokFQjwv3BdpDe+/ej5klah7p8l7JmEhKYuu6o salN9m+30QfRV2da0VV5KlVjdVpF1R/djv6ZBuUKSizivTwgLOCIf2x9dYFqqPqT PmOIr3wMgMug5/LjOWTOrGXa0W7koEgvL9iyTPNGKvc/6BojhtlAtdDQKcM6XWUv SiNqj+mFYVtVmjxGJkIH =57Tq -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New Egg: miniKanren
isual noise. This is made somewhat worse by the fact that (else fail) is used heavily in the book, which makes no sense. If no branch succeeds, failure is implicit, so (else fail) can be pretty much removed for this reason in all instances. | 4. the latest version introduces disequality constraints (=/=) as well as some type-constraint operators (absento, numero, symbolo, booleano). These are the most interesting change, because they allow you to do some neat things that weren't possible using miniKanren from The Reasoned Schemer. William Byrd has an entire chapter dedicated to =/= in his dissertation, which is pretty brilliant in it's own right. Using the constraint operators, there's even implementations of relational interpreters built on miniKanren (https://github.com/webyrd/quines). Nonetheless, how to use these is pretty simple, but I'll just stick to =/= for now since it's probably the most useful. The easiest way to get to know it is to play with it, so here's the simplest example: ~(run 1 (q) (=/= q 5)) ;=> ((_.0 (=/= ((_.0 5) This tells us q can be anything, as long as it's not 5. On it's own, not very useful; however this turns out to be useful for rembero, defined in The Reasoned Schemer, which normally looks like this: ~(define (caro l a) ~ (fresh (d) ~(== `(,a . ,d) l))) ~(define (rembero x l out) ~ (conde ~((== '() l) (== '() out)) ~((caro l x) (cdro l out)) ; The car of l is equal to x, or unify ~((fresh (a d res) ~ (== `(,a . ,d) l) ~ (== `(,a . ,res) out) ~ (rembero x d res) This is the definition (slightly modified) that is given in the book. However, if you run it: ~(run 3 (q) (rembero 5 '(5 5 3 4 5) q)) ~;=> ((5 3 4 5) (5 3 4 5) (5 5 3 4)) Which is incorrect, because rembero should act like rember, which only removes the first instance of the atom 5 from the list '(5 5 3 4 5). The only answer here should be the first one (every other 5 removed would be an error). So the fix is easy, tell rembero that before it can recurse, x cannot be equal to a. Since we only want to enter the last branch if the first and second branch fail, then we need to be explicit about this. Thus, the proper way to implement rembero: ~(define (rembero x l out) ~ (conde ~((== '() l) (== '() out)) ~((caro l x) (cdro l out)) ; The car of l is equal to x, or unify ~((fresh (a d res) ~ (== `(,a . ,d) l) ~ (=/= a x) ; The car of l is not equal to x ~ (== `(,a . ,res) out) ~ (rembero x d res) To be more explicit we could also throw (=/= '() l) above our fresh clause but (== `(,a . ,d) l) does this already. Now our example: ~(run 3 (q) (rembero 5 '(5 5 3 4 5) q)) ~;=> ((5 3 4 5)) Only one answer appears. You really need to play with these features to grasp how to use them best. The idea of using disequality to be explicit about branch selection is weird, especially since it doesn't match similar behaviour to cond, but that's just a part of relational programming. I apologize for the long mail, but hopefully this summarizes the majority of the changes between the languages. William Byrd even discusses some of this history throughout the following two videos from 2014: https://www.youtube.com/watch?v=zHov3fKYqBA (part 1) https://www.youtube.com/watch?v=nFE2E91VDAk (part 2) Unfortunately they are quite long and I don't have timestamps for any specific references or quotes. They're fun to work through though, as part 2 he actually goes into detail into how to build a relational interpreter. Hopefully that clears things up, sorry to the mailing list if this is too long and too wordy. I only looked at the length after writing it, and probably could have turned this into a blog post of it's own. Regards, - -- Jeremy Steward -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJWyMcfAAoJEHVwwAZUeZnZgOQP/RteL1dof6bgaCFf6Ytdwz9z P8/UfdR/7/3U3MqPydnq3YTnz/qOCgPSwNF39NlxFu6Ndcs2IvCPP6AR94ZJ5p4b eMaH9juF0O5u1IbA4N3I7xmbNLzsnC1h8UuMdpafSEUMki2F9rsJ6uFFepZi3Dc4 vf5AueLhaTlFZ+6/81CZ0z50awQPQjKnXweqT7xJv4c7kI18GxEyusDRE22iokyd t9K537ohRgUsgfrvK854Lg1KWgotVgLUQBn4YMDkSu3pzWVmUE6tLPPOw5KYz723 mDIzVvdIJzXsdtwP4yMQ8rUBISV8nQKlJNZen7VpDty3FJJ/jeiNhHWTEkMMOkvT XW6atH2FVxqtaHCbf5DarKRY6ciTs0l4VjqWVc5Mb+wdu7TvvB4rkmN/YInLLe0w Sd5TgsZf1/VKPlSWi6Lcr/wePHJOcVqIPmUYlJE0zw5LOL/m6VCxikv0H6qm5a8x Ej3djbVgQxnSbd6BYjevZw4VArYFziu9chdCg01jceBrBOyfOfhZEICyYFpNeHJE Rv78Tj4w3t8FAxhZ4v8zL+kh7R0Nkh9odw2n3KN2QQHlSlg+IukJG1VlLsMjzpXl ucXFUv7tA976neF7fgU2g9mO4BLxVMFD9/XIjfWcnvPxZKO3mePddSStxosOpM/n nK638k4tyyjppRPUu0Wm =BjxG -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] New Egg: miniKanren
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello all, Hope you all find yourselves well. I am sending this today to announce the 1.0 release of the latest miniKanren implementation. There's a bit of history here, so I'll try to summarize. However, if you're interested in seeing the implementation use the following link: https://bitbucket.org/ThatGeoGuy/chicken-minikanren We already have the "Kanren" egg, which provides the old Kanren language as well as the miniKanren implementation from "The Reasoned Schemer" (Dan Friedman, William Byrd, Oleg Kiselyov, MIT Press.). While this egg is great for working through the examples in the book, it does not provide the latest implementation of the miniKanren language (as it has evolved over the years). The latest implementation of miniKanren (found https://github.com/miniKanren/miniKanren) is unfortunately both very different and incompatible with the language of the same name used in The Reasoned Schemer. Although they are both similar, there are some notable change s: 1. condi no longer exists 2. conde now behaves like condi (to provide stronger termination guarantees) 3. else is removed as syntax from conde, conda, and condu 4. the latest version introduces disequality constraints (=/=) as well as some type-constraint operators (absento, numero, symbolo, booleano). After some discussion with the current maintainer (Alex Shinn), we have both decided it is probably better to packaged the canonical implementation as a separate miniKanren egg, while he has agreed to rename the mini-kanren module in the "Kanren" egg to `reasoned-schemer` or some such. This means that people working through The Reasoned Schemer can still use the implementation that works with the book, while users coming from Clojure's core.logic or Racket's miniKanren implementation can still use all the facilities that they'll be used to in the latest version of the language. I would be happy to answer any questions if there are any. Mario, could this be added to the coop, or are there additional steps I must take first? Best regards, - -- Jeremy Steward -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWw4bUAAoJEHVwwAZUeZnZ0p8QAKJH2MeT5E9vT2/2seuT0gex tbq8XFyzNWaKTUO9t97Dew4vcKLCKL9iFOZPep4OihAb3FskjfxqYSCQxTdgK0PC EBsDHNqaBdaZ7O3Olt9xLZ1MUb0cAtYsg1A2FHE6WPlPaT5tqGptOmcnJpRrSkx8 gnV5i5yCdwUxlaW8YXNOy8ZbJyuxF5DdGgBEirhkevyfYVDcYKcmAEf8WtXiXOS0 5VXYajS3LLyIGRi7TFo5sCBeqmd4rEKyNdF6eQK1Q9wGidA7Zh8Y469xqa/s03Y9 gccM8Njc9x7SId3TF7VQuIdKyfGNAY5pOKLPSTsEhzzB5tEEV7nJj4Jy7Ka+FgcU NWBEINnj46Bkxk0bVi3azddDf1W8p0K3K0Jo5X3z+O7ekeXA3MnKUOAyGk1+6Sfl fbDw2e7HhzYpgjaayWJ4Qb/aHq44uqBF/xtvUTBlGj9ZSrvwb8h8FzgpZulaW5+u 9yEtr5Qj7I/slW3u66ZpulzhkvgdJrzgg6OL/fsOcFvEI0vPUjMHxLA6AAO90ub+ IFcpGIf+kH2gmQHxs/nFE4CgrFm4J5DqaGb4+dRHkTmkfPFQFKauWYmFUxrOtFYl 1RZ4uzYZnYUgRCgsSnSHczrmLzlhDkj15X+xr+bNXNKxE6bFqVi8PD8tzdixtToK In3tGWjUAN82WEAE/sKp =5zJu -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [s...@speechcode.com: More SRFI reviewers needed.]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 | SRFI 127: Lazy Sequences Sorry as I do not have much to say towards the other SRFI's, as I am somewhat ignorant as to their process, however I noticed this one and could only think of the lazy-seq egg by Moritz Heidkamp (http://wiki.call-cc.org/eggref/4/lazy-seq#author). I've had a lot of good experience with the egg (although at first I will admit its usage confused me quite thoroughly). Nonetheless, I noticed that the SRFI document mentions implementing lazy sequences in a different way (utilizing SRFI 121: Generators, which is also on your list). I was wondering if the lazy-seq egg has been brought up whatsoever regarding this SRFI, and if there's some difference I'm not seeing here. My understanding is that the lazy-seq egg wraps the lazy-list in a record type that encapsulates the first element and the generating expression, but I may be wrong. Other than being able to use (car lazy-lst) and (cdr lazy-lst) normally, is there a specific reason for the difference here? Apologies if this comes off as noise on the list, this is purely my curiosity speaking. - -- Jeremy Steward -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJWjfvfAAoJEHVwwAZUeZnZO5QP/jDZpFv7pGudwhs8Wd+Wb77t wnFZsJ67d38SaAwmdjyiBBSZIhw/10zwvGVtOw4a2AM/t7IO4yUXAEzLIH7seQYh Q/pyzqkV7ebW71awfO0CkNFgN/SbEf3Vj7KOt1fRWiPL6IUw4cX8VYW9u4eSpWh+ oTtxyQAlEB4QsqLiOJdlDyyJXQ3fuuBbXTdqiosskFM47I9WfLXixlEtcoT4uXxj D6s0yqGGyG4rqAFfHU6ChGXAn/5K8Tmzf531V9IuKteTyXG/g5es2Bb6oFjlXYIQ hYYEByhkxkqjn+VvWL3v5mHsnjJg+Ao4nYSs/P2R1T3rH6lpbfNbBNuCjmIKl58t 6HuqW9JuiW1QW3SFnvCdqtCrt4wxL0lBoZ/zxy+3z20gfr0k8f2DmV+u24JzduRM HBeO3abAqMtsMjWowZNlCTkKNaOv2zErG/9fiwFB0nmDS+Zvxz85xMrraWqdoy7Y qZcEOE8ksVkcJaB0u4tCe+gBjTIkglQ2kpRoSIor5ljYr5TRMsSMNhfm5CAwakcC WIN+bm1VysEd0GY8LscRXjhBBJDk3qJjvk+T6N4xD/POv5C8ffR36Z7Kk1eF+6jd WkQ6qD4sbt792Cggx1jfCjQr7/0OnL8R5dsZkLtMYNjjtM9Gp9kwskkJ/mnBdsxM 8PSS1wP8FGmMLmauE8PT =1lnM -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New SDL2 eggs; help wanted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi John, I'd be very interested in this egg, especially if I can use it as a means to learn SDL, but I do not believe I can directly commit to using it, as I don't yet have a use case (though I have always wanted to use SDL to visualize point cloud / LIDAR data if possible). In any case, I'll watch as the development progresses, and re-evaluate whether or not I can afford some time to sink into learning SDL and using it within CHICKEN. > Currently the project needs people to help with: > > - Manual testing (installing, running examples) on different > platforms - Writing unit tests and semi-automated test programs - > Writing API reference docs, guides, and tutorials - Creating > detailed installation instructions for different platforms - > Creating feature demos and example games/programs > Some basic tutorials for setup would go a long way here, so I don't have to worry as much about getting SDL to work as I do learning the API and how to manipulate data. Bear in mind I don't consider myself either a clueless beginner nor an expert in the community, but something basic would certainly help. If you're willing to walk me through it on IRC sometime (find DeeEff in #chicken), I could even write a "hello world" style tutorial myself. I would venture that it would be better to get a more solid API before something like that, but it's up to you. That said, I'll keep watching this on the mailing list if it pops up, so please continue your work. I'm not in the business of making games, but SDL can be used for more than that if I understand correctly. Exciting times to be a part of this community indeed! - -- Jeremy Steward -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJWOvyXAAoJEHVwwAZUeZnZAjUP/iTvAWoCV0qOQ4tANIg8yLBi IF20smwiP0bhVdp1FttW8IB2Wx7DwCX/IF0Er3mf2NSenIaNmEl2gsMWbkn6u+Xj YZozAV3GwlmM4UGnK5kmAIL/cYa9eF6r+FQPKD7FlSrgzOkVgMYNjZ+Nyr64btKU V0pylCGIj0tyvPBY0zWjQLUnfOTVBqqvxk5JjAiLeEdmAUEKZRRi2iyaflUu4w4O KFe650MBv+lRiIUrnE3QzRoA4ulWdQe70OxSFY1pH09sgrNejpiIjMh2in33zBLc bWwtGBmR9WH1GZLBSuoRBgG1MvZdqLMGIDPsldHWe4FOW41Xv5/QuyKdjqGWFaRU C7M5/tSDLbZTGtWy0i52SY92cOH5FCYz9h92V7yXfcPa5EKh7vFlrcEvborIiOIi PvsU9lOC51U5e8b9qF5+QmpRRza23o8EMIS6F2sUDkrLfAgJ+DKX9Fm7q/+HOtR4 S1xgNbj4CDHYIfklILtzrwVVqPqdAg9+kZ1P1gPaLvDt0W9yX8GflBYrBde84qkC TJcQtfaDei+desfqomvOEgi9+56nJSlsGW9gYLjtpj94e51ZTr7c9i9pEipYaf/+ xouE5wrIqsVcQ1dPMobKO+XfAHyo8M6v0HlEjGJ6YD1Rbo593X3jnrjNl0CJFr6e FZGBV4b3XeMq3QJLaPZn =TGDD -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Hypergiant egg install fails, and some other eggs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I suppose as one of the few people who has used / uses CHICKEN on
Windows I should chime in :)
On 02/10/15 12:57 PM, Peter Bex wrote:
> On Sat, Oct 03, 2015 at 02:29:35AM +0800, Robert Herman wrote:
>> Maybe Termbox is too reliant on a linux terminal as the target,
>> but how come Blas fails, when I have the Blas libraries
>> installed, and working in other language implementations?
>
> Hard to say without more info. The Blas egg is a bit of a pain to
> get working, even on *nix. It has its own attempt at
> "auto-detection" of how it should invoke the compiler & linker,
> which is quite error-prone and probably very Linux-oriented anyway.
> The reason behind this seems to be that Blas itself is a bit of an
> old-fashioned library, and doesn't have a way to discover how to
> link against it (no pkg-config, for example).
BLAS is problematic not because it is old, but because it is made
available through multiple implementations. For example, BLAS can be
made available through Intel's MKL, ATLAS, OpenBLAS, and of course the
original netlib.org reference implementation. Keep in mind BLAS is
often implemented in Fortran and then exported to C, so depending on
your implementation you might also need to expose `-lgfortran` to csc
as well.
The "auto-detection" code is more or less attempting to figure out
which BLAS library you're using, and tries to deduce which files to
link into the build process. You can, for example, try the following:
#include
#include
int main() {
cblas_ddot(0, NULL, 0, NULL, 0);
return 0;
}
You'll then want to compile this as follows:
gcc test.c -o test -lm -lblas
OR
gcc test.c -o test -lm -lcblas
If either of those work, you should be good to go with regards to
installing BLAS automatically. Otherwise, you may need to figure out
where libblas.dll or libcblas.dll reside and you'll need to expose
those libraries in your INCLUDE path.
If you're getting weird errors with blas or atlas-lapack, you can post
here and I can try to help. I did some work with atlas-lapack earlier
this year (and I mean to do more), but I've had good success with it
on Windows thus far.
>> I will try and see why other eggs fail and look into tracing
>> them, and share what I find. I really want to be able to make
>> CHICKEN my platform on Windows.
>
> Don't give up! It's just that you're charting new territory; not
> many people are currently using CHICKEN on Windows. Most egg
> authors will be happy to patch their eggs to make things work, if
> you can inform them what is needed to make things build on
> Windows.
Agreed, please do not give up. Currently the way I use CHICKEN on
Windows is through Cygwin, because it is currently the easiest way to
install and link things (using plain MinGW64 is an exercise in
patience, IMO). Hopefully the midipix project (http://midipix.org/)
picks up, which will provide a much better way to use CHICKEN (and
other C libraries / programs) on Windows.
I suppose midipix / musl-libc support should be it's own thread though.
Cheers,
- --
Jeremy Steward
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBAgAGBQJWEVjOAAoJEHVwwAZUeZnZ31YP/jmwMZYQ0T7UjGdoZ5an1lXH
NSBuEebN1888RzMbmNVe/nWLq/RhTrEZZpGJ4m4/IeWA09PBLSLEhe/E4JBAjV1d
v3Rx5UlAUTSP4zh9rP4sZO9EV09X7xbTh2IoIjU3udyJ9SJv/XqHU0RyIsv4xmum
EjNXoCOswBkfZLZ8ErsKUPyYWykS1F8vQ0QSxNoYdnfiDnhtfpNKV3w4+f6CUtKo
QxHWzUf8UGT9My0PHd0ZMgqsxumuXTSZs9OTFEphjys4BOSz/ppVROe840Nj8GOb
qutG0/ELRoEJoMcgBhNZSVXqFkvgRAkoB7U9iv5pc1e+5+qDgNKgUyqTxNdPH8pA
DRskUMotAcwqjF5gSp6j04HikI7resIHzmshzyO+rT9Az6AervDereFIBCULzeTh
D7/iwCjvEaDxUlFDt5nOeXA0APVSpzYYwKqKAnQQ3Mu7gNt18EzC0kuVmqakTAuC
4X6uKyoKFFUk7e16tQAyzfpzvrtpRVm4J/I2wBuRF+vmFlGObAWg1pPkdS+mIbsZ
/v1VGiQxW3f7AHa2jiMHkj7lipqKOHCglD3dh9kpEJMdOHxFaZSRwA0EbxWoh/rm
5MCZ0VkikZC2FiVvnAqyqqUnk0dV9YY+0+SPcLR8Vr5RFETr1h2dgh6QzX+ZUSpO
87yk7FsY40OB1HW29Icj
=YCKH
-END PGP SIGNATURE-
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Hypergiant egg install fails, and some other eggs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/10/15 11:09 AM, Peter Bex wrote: > On Sun, Oct 04, 2015 at 10:50:24AM -0600, Jeremy Steward wrote: >> I suppose as one of the few people who has used / uses CHICKEN >> on Windows I should chime in :) > > Thanks for this! > >> On 02/10/15 12:57 PM, Peter Bex wrote: >>> The reason behind this seems to be that Blas itself is a bit of >>> an old-fashioned library[...] >> >> BLAS is problematic not because it is old, but because it is >> made available through multiple implementations. For example, >> BLAS can be made available through Intel's MKL, ATLAS, OpenBLAS, >> and of course the original netlib.org reference implementation. >> Keep in mind BLAS is often implemented in Fortran and then >> exported to C, so depending on your implementation you might also >> need to expose `-lgfortran` to csc as well. > > Thanks for explaining this. It's good to know about that. Do > none of the BLAS implementation offer pkg-config support, though? > Even if you only support one BLAS library, it can still be > installed in several different locations, depending on the platform > and packaging system used. As far as I can tell, none of the ones I mentioned above do. The OpenBLAS guys would do it, but their issue tracker on Github suggested they don't know how to write pkg-config files [1]. As for Intel's MKL, it's proprietary. This means 1) I haven't utilized it much, and 2) I have never seen it play nice with FOSS tooling. It could very well export pkg-config bindings, but I doubt it. As for ATLAS and netlib BLAS, they both suffer from being maintained by a single developer who hasn't updated the software much (beyond architecture compatibility) in years. That isn't to say that ATLAS is out of date or bitrotted (it is in fact quite optimized and useful), but the code itself is robust and well-tested, and prioritizes platform compatibility over new features (IMO, I don't know or talk with the developer, but this is the impression I get). >> Agreed, please do not give up. Currently the way I use CHICKEN >> on Windows is through Cygwin, because it is currently the easiest >> way to install and link things (using plain MinGW64 is an >> exercise in patience, IMO). Hopefully the midipix project >> (http://midipix.org/) picks up, which will provide a much better >> way to use CHICKEN (and other C libraries / programs) on >> Windows. > > Wow, this Midipix project sounds very promising! Definitely > something to keep an eye on, so we can (eventually?) get rid of the > mess that is cygwin & mingw. > > Cheers, Peter > Indeed, it would be a great day when Windows is as easy to support as Linux or BSD! [1] https://github.com/xianyi/OpenBLAS/issues/598 - -- Jeremy Steward -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJWEWtRAAoJEHVwwAZUeZnZh8AQAKjGh/LqhSce/3gzWXSFeL8Z ESk7ttbO3qszc266w9gTFBpA6HGaloLawy+3/PfknHnbV8lvr24Thn/gikfx0ja/ L/9BpCKwr48eQelWmKVQdf5VPaAk2xk49tqhtqF0WMsUX6ppBeIiNMQH1F4EY074 M6iAZXfvdaxiuYx7i3hhKiNHiXuCWRDqEF8Uot10FIgbnvlF5wmJbbJjKXrYmX/R sa1JeUmLZYamSRbYP/PY0o+X/brnhWrYD5nrAcbZZeyWXPSYjQuvySk3DLXsly3+ YP0H3darVuQu5s81WNLDMm5xm6pGs2PbAFZy24YHHBuVtKG44gdPyGTAI5NeZL/V IDzsTWz80pD2mEkp5ll5pSn72giUofYo9ryYLL2oYhBeomqmv0x2kcmJdreHfjc7 6OCjoRNaIjzdfcu2kRZQBn/ZllWuNEPhxOKB296ptaWN8aBk3fX/ryDYF5S79KfW uwpsueOzHvnACvIesJD/7YmCde+Z20560nV8GBdiu8dJdpYCoQWY1wLrDCYhF1Z2 AS9jxUpkAMYjHsPWBFM5O3vifytpuJDvebLRhP6U9Eydgw+0Uz1M45NZzH/y7pLT 0KABXqWvHiBnwmaSN7wuJlwAIc7B3bAO4MCGPMXGYY4aEPRLsw8nCG8b/8FT2QU/ WiBsGMsp17ccdbQUkW4N =f0Rp -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in readline 4.0 egg; missing function (Erik Falor)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Would libreadline versions factor into this? On the machine where I am experiencing this error, I am using GNU libreadline7 ver 6.3.8-1 from Cygwin. Further, I'm using libncurses 4.9. Let me know if any more information is necessary. Regards, - -- Jeremy Steward -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVxS4xAAoJEHVwwAZUeZnZ3qMP/0M6mVGEsOwI95LVhZSWxCHu C6i0pDXNcP0dsVs0P63q+xktOSl4aDfLPj9EmG4ObCj1iWmv4tir+H2I0PqIKWdE etNE+KlHRqDYoR5qEdhAnQCON0m6aVI6hFboY01CXEyG99RmfgFWGbz5cMcm6svZ 36pqkck+PbI2gBXU3j7E0by75u0Y0OSVeTJzgMxFP6ih26oWS8T2fqy3UtX6aH2C TEcLPJ6BPrHHAczcO1GURzwIz1rT4FKUN4RoW3MAUgtdUiH6NbVfgIkxhgGkboj8 IZq0jRbCMV+LUxOWHAnrDpB3jRhAQPNP3plxNlC/V5b2J1HOckLalZ13N1pDBbvA gNPTTclxQ3G63MaFwX9QlSnhtWCcQ47E4NBnrKIe/qjiX3lbGlgjIOC1qTUVBoKt ZJu6j7e6TN+n8QH6PrnUQJAlS2RDG4VAW/BMs7c6O1d9xkLBprLiG8bkHpxu0SB3 If6dCVnK/+hLa3LTd9gefUqI4lazLHaGUYjYv3aqBVi9k5VXE/miGyP/avLfXOJO FiGAfwZ/1oSKtYomR/OSa55OhifF5EjCzrIZH47VSwCmmReTJEZay8KsLg34JFSQ p6ikuD79bc0/deDQPlyqnx0iDvnbki4BMhobNoRGZlHZJaw0Qq2zlvJQ4cn6iC8V Vsc9B8ubvwAGhJ4Scu5N =fIEz -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in readline 4.0 egg; missing function
-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
Re: [Chicken-users] CHICKEN 4.10.0 has been released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I'll just chime in here on the side, but I believe I made an edit to the wiki quite some time ago about switching to mingw-64, since at the time I had some issues using the bind egg. Moreover, while I have not tested CHICKEN 4.10 yet, I compiled CHICKEN 4.9.1 myself on cygwin64 with no error,so it's unlikely any changes need to be made on that front. Cheers, - -- Jeremy Steward -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQJDBAEBCgAtBQJVxL4OJhxKZXJlbXkgU3Rld2FyZCA8amVyZW15QHRoYXRnZW9n dXkuY2E+AAoJEHVwwAZUeZnZNokP/0lLRxE0YimQuLmPt/P4lwXTaIejJMwbC8gB Cq9SBby8a+EoO5bsjaAxgZH+JTr8T00eESBogqkvFIt+0AWqAFcNvAcEv6/Z/Jg7 ecyHYmIe1CYlDZlAVMHznGacR48ga9G9eNK5xz3svIacLtWv2xTJwbxZntDLTR8K Fdg9MeeyBGcSVtrZMVE89q4F24v2Q2P3KP8BcrSU46LaDAhKqxDJTDPpIjYnnUQW Bx9HW29zA8XI5RFCUlDrY5RbApPeKHpbnfD1LCMDTY0ktzFRyEU9UkXBVUVZZiz4 4tjBu0c/95C6q7S5YruCESC275vlOlPXWI2OKMsiaYK77tSkToHqGSx3ArrGMWxE zP8EppAvfkB8wvulXhVtbmL+i09sAO7DpBXxQNeSdqou0QmWo4pmqT6YCxEw8zoE ANDfFFc3rJMGdwGg0Qb0NHqJhPiKqdcNsSTj9uJZa2pO08glXz5QHhMTx/yG3IWz 6AUWsJVj7JGJaALXL1p0wHtDdxdY7KeHwcRBGRuGwDFj5xi6r0dI2Z9aga8zbVGb GkHVZ6gXuKoSTBM0Q3zCsSBjjsGD6biBG+WGfM39JuKxQ+4oUqQu4c8CUhUx8pAP vXhD5ODyiE/rrBux0SVfuY+n5k/SaZFDMo0tb8P5gAO62WLyRzuzMtHT+1BTmbNB AGz9bDRY =SZ2n -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in readline 4.0 egg; missing function
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Would it be possible to replace readline with linenoise in your workflow? Unfortunately the main benefit of readline currently is that it supports history (linenoise does not, at least when I last checked). It's not the worst break in the world, as I can always use the SLIME egg, but that does not preserve history across sessions quite as well. - -- Jeremy Steward -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQJDBAEBCgAtBQJVxNwVJhxKZXJlbXkgU3Rld2FyZCA8amVyZW15QHRoYXRnZW9n dXkuY2E+AAoJEHVwwAZUeZnZhIIP/RmhB2Mtcgx3HsR18I15V5R/CnDUe7lwu/wp vNPBt1dW33GhSLH/6L0X4r5YOr+PtN5Fgklie4id1yQW6h5v15mis1pN5E6ouNBH bC3m0JVYI7/Luw4oJNjA5bcd+4nYBvLmMeq8MQot13t1dXKgomv5qfgmOrcq2ta7 VGQ7kOoxT7rDNJ97DIrcwPidBIWr/J6iVKdGaoNblGRuIi+2Ktwl4OjVH8FF1CrA q9jDsfSZGiY6cyZDxV3hVQ0zXsvD3JYuF5R63Ui5lVaE+HIJrB6+SaLF+GwX857w 1+k/BmuCgAXLo/I23O5bwkKlV6SUTCEDBGCz6NaeJdC9CNDxq/48BnKNWCQ3H4Fl 81xCTS90n4ZEm3WureJxGUAhXxSFqS8YZ8AGLDzspsKfDMxiVvcW7qO9jhldTyaa 4JUPZMMwpYMUN7q4FfSrLM18NsaWCR8QC/2EuibCVoh5ml8O8T2lX7e0rapJBSkM 8gv9dTLDHelznaSlxj+osfSvghyCWbL612PufuG5ZJy2urEm2G89gBH0yEwVHXZl at10yToxXFCoC5GKIAkTSdfbqBZRrAtzHXdmLVbUdrlFPeVfRIGYp3X6aGl0Z8f1 8I+vXLVFzWP9zDLJBpdDKu6g82JpXeEowxA/lPOzZ2yQFjE+AJvSsia64qEsdiKL KSrGX5yN =7n5y -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in readline 4.0 egg; missing function
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Thank you! This does solve my problem for the time being. Cheers, - -- Jeremy Steward -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVxOyZAAoJEHVwwAZUeZnZBdIP/iCLbztdsjVlswVHJ67oCWjo IOoDD4P2CUuDBUy1hjk/xFE+EUqUscY9HRD4sy5KHha313touOXuirSHGNWrfBfg JnoOOKAk1DfT/qLL1DdzeVqQPhiRLa7UCMAKd5TNatC3pq8B7aYvgxgkl9bfvuRt UpakUo4Uq81ECC0gqPyYThSk2KVCWkjdSB0Dpvt6FpyiT3lffVtr6hOfw9gnWvY+ /wW4FxePlxccONwooq/gKTD6SCsDJoDKwnaf/XC5nnF+OUI9KF1fxPD1qevICKOt J3xvWH1c9nB98YhW84FUl/o+liVQUT/1B8d1xlJnY/0cLPr2UzfRHkIy5s9i2Cor EkniDSZxlVL3+iIw12Z80WGcRjlDDqsQMIneXo9hTwTyC3Om054o/K9v06ndRFZ+ Eq1fZeeTNtyYykznJ1VX02y8IZjf3hbdMWaSb+wD7av60mrsPn9l2GKK0WgYOELe cNm4Bx/N3d1g57cHsW7wjdpBZqo0XDjzp+0cjnPysLaZ4DFN6MXDBrl4JrQI1EVv LfXOfWZsTBC72dcX3GXTvlcig1v3nOJ8KSRivwe33XaIedQfeQ1ymbTBc+ufMi3j n/6SyCxUrmBUj+iMw/qfL421vCLj8rvD3QD6mI0QouwnTJI3VJ+I1xuVf+ONfFiM 1+PibpKRhM/M7jIRLGbG =Mge/ -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New Egg: chicken-graphs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Mario, Thank you for the detailed feedback. I've taken the steps you've listed, and as far as I can tell salmonella is not complaining (outside of lacking qwiki documentation). With regards to documentation, do I just add it to the wiki once the egg has been officially registered? That should be simple enough, I believe I've made edits to the wiki before, anonymously. Cheers, and thanks again for the helpful feedback! - -- Jeremy Steward -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQJDBAEBCgAtBQJVlsMNJhxKZXJlbXkgU3Rld2FyZCA8amVyZW15QHRoYXRnZW9n dXkuY2E+AAoJEHVwwAZUeZnZgAsP/3lrR53lwCnpiDIreGEcosWAPG5A0dxyCeQ6 ySDcdLbBIr4vqAdik9D9I/kNOvDW4dp0B4yFWEcwiHsgpKjyqH9FTFpfmTENMO0X lW4cjCqmUsbJ7sSh+j8gA9P2HrP4rVmq0z5v4chgbqPXuTnLLwQ4pvzdONrfHoEd k09jgbIN1eDxlsSl5uDHoaSG6PZjOgytjmmt067SMZudUrw+kj/gPIDMrqsxDDPb /bfn1zUM4bm5FpD80IBqn4yj+JNNe9rHfN7EYmBb6f+gEDaQX91NHfw6z4kyPa7d JeeNO1MWXEBo9J8dcOiuStO2GbyrStyfZWgK1qayWjzj2iUplVH5iTXo2ABYputC +P5T1iY9LPSNQuvv+RUyZpDFjo0ApkwKsyDKls4i04EQdcuIur0v/LDyaSQj9Hrx eqAEYsXj45HwcJXZYy1/5BvnyizqR87Cf0dGoeZ2BGM0LczXO50pytLHFc5ui9oE kjF7sqnljCa2rcDTje4oq68r1ROPfGwhBUTUbxqVnKuz0FiU2qYNCk6z2AirJa9X nz8MUCAwNGHvPvO7O/7YG+4nPDCsERTmwM8LjPee54hflklW+2imcI6/vRl+V/2d OtUYZevHFAS3fvL7klMAvPx0RDPr+X7oQ15KLL2hOBy9T9qoz3vhyZ3VgL+lC5Be hK4ZevXc =6FJb -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] New Egg: chicken-graphs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey all, For those of you who do not know me, I also go by DeeEff on #chicken. I'd like to announce an egg I've recently put together which provides a small set of functionality for graphs, digraphs, multigraphs, and multidigraphs. I am aware of the digraph egg as it stands, but I developed this both as a learning exercise (as I am currently studying graph theory), and in addition, that egg does not support the entirety of graph types as I have listed above. The code can be found at https://github.com/ThatGeoGuy/chicken-graphs, and the license is the LGPL3+. I plan to add more functionality in the future, I'm currently attempting to implement some way to test for isomorphism, but am not quite at that point yet. Things on the TODO list are as follows: TODO: - - Documentation (I know nothing of qwiki format, but am using hahn (partially) in the code - - Tests (this will be smoother once I implement isomorphism?, as I am using test-generative and a solid isomorphism predicate will be useful for that) - - Users. I need users to use the code or at least browse it and let me know if something smells. :) If there are any issues, I would appreciate if users could email (mailing list or otherwise) or use the issue tracker on Github. Cheers, - -- Jeremy Steward -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVldy5AAoJEHVwwAZUeZnZ5bMP/2/LMlA1p4tSZLRvUv+/jYP/ RWQQ1B3QCV3oYSXeZ9rJWYkdsE/HKmk5xZVjEP3eQgYL8Ef9OESCkRpo1UAU3W/G FNhZbWgoKvm2hrFeQtM5JSzvJOG9cKsUQ9sBkTB4U0gc3Y0AlDHbFMIbPRW6IjVN G/UkSohxNlVo/8LSp5FJEUplrxgVp4ZUfYHz/Wt9HFwDA7pkLdU+RfyGpVvtWemG qH5f7Q/WlglQCh5x1gns/AmxwJwUWWr6O6IeHXu9a0GQDApzogJJbW7gTPz2k9rM 8rKHe79J7IA9SFDWV0a6UDGKMxH7TStSSJ6P99/eoiylnIgBDandBrSNuV29UcQ9 8jafGbYbJOgRzASSvQkcUzyIECHRuYzRYSDo4Oxr8SOAqioYzfWN+F92TduSlgjO cu+S8vcfq7Nm9UKUVxw3KOM0JTlNpUNa3SZdmBUTVfLaWD1CeuyeP+TUMLze4TL+ L3RFW0xEIHi2dgeXx++S7VySU3V6UqVGUZa7LO04EfvNkrWjVZieofAwVRKCepfO ATagfv3JIWV7LtnUs7Z4/+QMSnfxGhUOZbfNrgfVxI0HX5VRSVk9hGuG1JjuUNGh 6159gEywOtAtbi9p+o/C5IRAwzJo/8IVjbQBXNL2/UvoamoxCS5YYtuHXvfYqeWq S1VbJ5a1UmSMDKKewcb7 =iEFq -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] IDE for Beginners
, programatically ff-paths - $PATH-like searching in C-x C-f; filladapt - enhances Emacs's built-in adaptive fill; floatbg - slowly modify background color; framepop - display temporary buffers in a dedicated frame; graphviz-dot-mode.el - mode for the dot-language used by graphviz (att). highlight-beyond-fill-column - highlight lines that are too long; highlight-completion - highlight completions in the minibuffer; highlight-current-line - highlight line where the cursor is; home-end - alternative Home and End commands; htmlize - HTML-ize font-lock buffers; initsplit - split customizations into different files; joc-toggle-buffer - fast switching between two buffers; joc-toggle-case - a set of functions to toggle the case of characters; keydef - a simpler way to define key mappings; keywiz - Emacs key sequence quiz; lcomp - list-completion hacks; maplev - major mode for Maple; map-lines - map a command over lines matching a regexp; markdown-mode - major mode for editing Markdown files; marker-visit - navigate through a buffer's marks in order; matlab - major mode for MatLab dot-m files; minibuf-electric - electric minibuffer behavior from XEmacs; minibuffer-complete-cycle - cycle through the *Completions* buffer; miniedit - enhanced editing for minibuffer fields; mutt-alias - lookup and insert the expansion of mutt mail aliases; muttrc-mode - major mode for editing Mutt config files; obfusurl - obfuscate an URL; pack-windows - resize all windows to display as much info as possible; perldoc - show help for Perl functions and modules. (Depends on perl-doc); pod-mode - major mode for editing POD files; pp-c-l - display Control-l characters in a pretty way; projects - create project-based meaningful buffer names; prot-buf - protect buffers from accidental killing; protocols - perform lookups in /etc/protocols; quack - enhanced support for editing and running Scheme code; rfcview - view IETF RFCs with readability-improved formatting; services - perform lookups in /etc/services; session - saves settings between Emacs invocations and visits to a file; setnu - setnu-mode, a vi-style line number mode; shell-command - enables tab-completion for shell-command; show-wspace - highlight whitespaces of various kinds; silly-mail - generate bozotic mail headers; slang-mode.el - a major-mode for editing S-Lang scripts; sys-apropos - interface for the *nix apropos command; tabbar - Display a tab bar in the header line; tail - tail -f a file or a command from within Emacs; tc - cite text with proper filling; thinks - quote texts in cartoon-like think bubbles; tlc - major mode for editing Target Language Compiler scripts; tld - explain top-level domain names; todoo - major mode for editing TODO files; toggle-option - easily toggle frequently toggled options; twiddle - mode line hacks to keep you awake; under - underline a region with ^ characters; upstart-mode - mode for editing upstart files; xrdb-mode - mode for editing X resource database files. . See /usr/share/doc/emacs-goodies- el/README.Debian.gz for a short description of all files, or the Info node `emacs-goodies-el' for details. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users - -- Jeremy Steward -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVOHWTAAoJEHVwwAZUeZnZCa0QAJoqQF2xtSXmttuZpssaAxLY 87D5KP1lcJ9AmyXGCeWGlIvv+mTET6oBwtW9TLJFvMYx7RzBwBQFxmu4Hk94reMN 9845D7mXQCTWLAVHDfJ0Q8KfWKSgmouWE+tIEOMdliDky+ikcoNtGkD3bCLNBM/G wRhj14vrlIx80QbG9uDVLYgoNBs5nkbopTT3nfVXq8TwY8Cc0x+IhOPo1kNCxCfk QLdvVfeEw48HvWdKhm/H0MPgx/+iB9uyxkk+XgRMbQJpuRxqe5NcRPgBpaYpx0E9 cXn38ODRYtE7pWzLCriewsBLSNwFXNdT1bNfl7hjA4fgz3vdUOmp1dVPsyU3trif ADEatcee8wWEa0Bsggeb264iYNKEqwrpw18x7z/lvNLlHUeOW8Sud90QOYHyBa18 qtn0mkHFrTSs4A3f7GpS4nWreGokolkkysFbRmS1aDbIgEDCKVZjhRPMoaPZdjJf CpXmMMGKrqwI1G77xkBlbZ3j4bho9QAEqG99QKIqXr156RPEzxE6elaOBruJwW4t bozng/LpjHA2RD48+fjT6cjcxHL3rJtLpvbg++PX96iOVnf8Whm5ltWWhTG0B03H 0DYSd+jHajMhRGsOqCjbvnJkw1OK4+Oj/NrycpmqW5jbWMRAN70OD0LaBlHCFEkT rq8YH1M+FgtOzrsdk0uy =3Q/3 -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
