The "-static" option passed "-static" to the linker which results in a
statically
linked libchicken + libc, which is unnecessary. With this patch, libchicken.a
is linked only.
felix
From 45d1c25f0548589114cdaeeded2f9674fe9b57b1 Mon Sep 17 00:00:00 2001
From: felix
Date: Wed, 18 Oct 2017 10:11:
Hello!
Due to overly eager loading and processing of ".link" files, repeated runs of
"csc"
when compiling files both in static + dynamic mode (e.g. eggs in default mode)
would result in linker errors, due to non-PIC (static) code being linked.
felix
From 946568e66a0dbb31752b774f73dc24de2d0e380
> A couple of the "axes" and the associated "values" they can have when
> loading code, off the top of my head, are:
>
> - Locations:
>- Working directory
>- Repository path
>- Include path
> - Type of source:
>- No module
>- One module
>- Multiple modules
> - Type of co
> > It has uses - "notice" is different, and can be replaced by a (trivially)
> > implemented user-made logging facility. This may sound a bit like
> > bikeshedding,
> > but we will break a bit of code otherwise.
>
> Note that the second patch I supplied doesn't remove "notice" or "warning",
> it
>
> Agreed, let's drop those from (chicken base). This includes the
> "enable-warnings" procedure, because it makes no sense to have a way
> of programmatically enabling/disabling warnings that only the core
> tools should be emitting anyway.
I would leave "warning" and "enable-warnings", as we
> Thanks Felix, I've applied this.
>
> Regarding srfi-1 and the other eggs with hand-rolled type files, is
> there a way to install those files using the "official" egg API? I've
> puzzled over this for a little while and AFAICT there's a way to put
> files into the "bin", "share" and "include" di
> - notice (we already had "warning" and "error", however, notice seems
> to be used mostly in the compiler)
Does this need to be exposed? I'm not sure how useful this is for user
code.
> - use
> - require-library
> - require-extension
> - quotient&{remainder,modulo}
>
> I'm not 100% s
Hi!
As pointed out by Kooda, there are a couple of flaws in the handling
and documentation of the "types-file" and "inline-file" egg properties.
See attached patch.
Notes:
- All paths are absolute now. I can't say whether this makes much of
a difference, but the information is there and I som
> Well, actually, I’m not sure what makes more sense. I think it’s
> strange that types and inline files are relative paths in the install
> script while every other file is an absolute path.
That was an omission, it should be relative.
>
> The other thing I find strange, is that the doc says th
Hi!
The attached patch attempts to fix #1369. The problem here is (or seems to be)
that .o files produced for static and dynamic versions of an extension may
collide.
Specifically, the static .o file will be overwritten in a subsequent compile of
the
dynamic version. Normally, the static variant
> On Sat, Jul 29, 2017 at 09:57:45AM +0200, lemonboy wrote:
> > Hello hackers,
> > I found and fixed two small problems in the srfi-4 module, here's a patch
> > (made
> > against the chicken-5 branch, it should be easily backported to master if
> > needed) that also includes some tests.
>
> Very
> On Mon, Jul 31, 2017 at 06:31:28PM +0200, lemonboy wrote:
> > Hello hackers,
> > I managed to stumble across this nasty compiler bug while trying to figure
> > out
> > why some code was segfaulting in a FFI stub. It turns out that I forgot to
> > place
> > a define-foreign-type form before the
Hi!
Attached a patch that removes "system-information" and "get-host-name".
An egg with these two procedures can be found in the chicken-5-eggs repository
(tested only on linux and mingw32 so far).
felix
From 7ad43ef5a06eeb5d0fad8c999061c9c0c601675e Mon Sep 17 00:00:00 2001
From: felix
Date:
> Here's another attempt at improving the sanity check, but if this
> keeps cropping up we might as well just get rid of the sanity check.
> On the other hand, it does point out several issues, so maybe it's
> useful after all:
>
> - Any symbol that starts with \x00 is seen as a keyword, which isn
Hi, again!
Peter and me thought that we move "system-information" and "get-host-name"
into an egg, since they are not used in the core system. The suggested name
is "system-information".
felix (+ Peter)
___
Chicken-hackers mailing list
Chicken-hackers
Hi!
We looked at [1] once more, and to speed up the modularization task
for CHICKEN 5, here is a proposal from us regarding the undecided identifiers.
Comments are welcome.
(chicken base): leave as is, but adding
alist-ref alist-update alist-update! rassoc
atom? butlast chop compress fla
> Hi Felix,
>
> Hmm, no, it shouldn't need any special cleanup. But, the patch didn't
> apply cleanly to the chicken-5 branch anymore, so I've rebased it and it
> works fine for me now. I think I must have simply sent an incorrect
> version of the patch before.
>
> Sorry about that, please give t
Hi!
I've tried your patch, and like the factoring, but when I run "check",
I get this error:
linking tests ...
/home/felix/chicken/chicken-5-master/tests/../chicken
'reverser/tags/1.0/reverser.scm' -output-file 'reverser.c' -verbose
-include-path /home/f
>
> From there, there are two ways to ensure they don't interfere with
> symbols that are spelled the same:
>
> - Make the lookup know what we're looking for and use the symbol's
> value to determine whether to return the object or not.
> - Create a new symbol table for keywords specifically.
>
> On Mon, Jul 17, 2017 at 09:06:15AM +0200, Peter Bex wrote:
> > On Mon, Jul 17, 2017 at 12:08:04PM +1200, Evan Hanson wrote:
> > > I suppose now would be a good time to discuss whether we should (1) add
> > > any warnings to this pass, for example when one of these FFI arguments
> > > is known to
pushed.
felix
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
> The question is do we want to drop the * export support from 5
> altogether.
>
> Working with the export list is painful without some syntax support. You
> end up repeating every identifier name otherwise.
>
> How about a pair of syntax called export-all and export-none (or
> similar). Every de
> On 2017-06-20 13:11, felix.winkelm...@bevuta.com wrote:
> >You seem to drop the reference to "destination-repository". Are you sure
> >this is
> >right in the face of cross-compilation?
>
> I think so. Or rather, this patch makes "-link" behave like "normal"
> compilation in that it respects CH
Pushed.
felix
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
You seem to drop the reference to "destination-repository". Are you sure this is
right in the face of cross-compilation?
felix
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
> I've got a preliminary C5 port of salmonella working. It's here:
> https://github.com/mario-goulart/salmonella/tree/chicken-5
>
> Not all programs shipped by salmonella have been ported (only salmonella
> and salmonella-log-viewer [*]), but salmonella is able to test itself,
> at least. I've t
> On Sat, Jun 17, 2017 at 07:21:30PM +0200, felix.winkelm...@bevuta.com wrote:
> > > I'd also like to hear what the other core members think.
> >
> > (chicken syntax), and keep expand.scm. Don't overdo it.
>
> Do you mean we rename (chicken expand) to (chicken syntax) in
> expand.scm (with perhap
> As Kooda found out when working on #1379, there's still some problems
> with the symbol GC stuff in CHICKEN 5. Sometimes you'll see an assertion
> failure in update_symbol_tables: assert(!C_persistable_symbol(sym)) will
> bail out due to some symbols being released while they still had a global
> On Sat, Jun 17, 2017 at 10:40:28AM -0400, John Cowan wrote:
> > On Sat, Jun 17, 2017 at 10:25 AM, Peter Bex wrote:
> > I can imagine those macros going into (chicken base) and/or some
> > > other modules, but a (chicken syntax) module with them in it makes
> > > sense too. Then we could just re
> This brings up the obvious question: what should we do with
> (chicken expand)? I was considering a patch to rename it to
> (chicken syntax) like we have in c-l-r, but should we then also
> rename the expand.scm file to syntax.scm? I think this would
> be the most sensible thing to do.
>
> But
> On Thu, Jun 08, 2017 at 11:24:44AM +0300, megane wrote:
> > Reexport is nice if you have a big module (say a graphics library) you
> > want to organize into smaller chunks internally.
>
> Yeah, but why can't "export" (or the export list) do that job?
Because you have to import first. IIRC, ree
> On Wed, Jun 7, 2017 at 2:06 PM, wrote:
>
> Isn't it easy to forget particular identifiers that happen to start with
> > "fp"
> > as well? I think explicit "rename" imports are clearer and less error
> > prone.
> >
>
> My example is bad: you'd want to use it with a module where all the names
>
> On Wed, Jun 7, 2017 at 9:28 AM, megane wrote:
>
> If the module export list is not *, module-unexport-list is not used. In
> > this case, it's enough to just remove the identifier to be unexported
> > from the module-export-list.
> >
>
> Very nice!
>
> While you are messing around with the mo
> First, let me ramble some:
>
> 1. If you hide an exported identifier the compiler is free to drop the
> actual definition from the compiled object. This happens without any
> warnings currently and you get a runtime error if you try to use the
> identifier.
>
> 2. If an identifier is not export
>
> Evan Hanson writes:
>
> >> Which foo should be hidden? Both, or none?
> >
> > Personally, I'd expect the following behaviour, depending on where the
> > declaration appears:
> >
>
> I did some tests with and without the POC patch I sent yesterday.
>
> Some observations:
> (these are the o
> I think we should strive to make library the first, and potentially the
> only, unit that the user needs to care about when distributing compiled
> C or compiling programs with "-explicit-use". These changes move things
> further away from that ideal by making programs that use the `time`
> macro
Hello!
The attached patch provides a "modules" property to override the names of
compiled and installed import libraries.
felix
From 7c974ceb55bba10aa4adbd0fcbccc1ad2661541e Mon Sep 17 00:00:00 2001
From: felix
Date: Thu, 1 Jun 2017 11:30:45 +0200
Subject: [PATCH] chicken-install: add modules
> > The multi-module case is indeed not covered. There is an note on the
> > wiki regarding functors that emit 2 import libs (used in some places),
> > this has to be handled automatically (compile + install .import.so
> > and _.import.so, if the latter one exists). Another option would be
> > to a
> Should extension components specified in .egg files be required to be
> modules?
>
> If I understand correctly, that's the case at the moment, as the build
> script will try to compile .import.scm files supposedly emited for files
> specified as extensions (they might not exist if the files don'
> Is CHICKEN_INSTALL_PREFIX intended to be used together with
> CHICKEN_INSTALL_REPOSITORY? If I don't set CHICKEN_INSTALL_REPOSITORY,
> extensions and .egg-info files end up in the canonical repository. Not
> sure if this is by design.
Yes, this is the case. I thought it is better to have two s
Hello!
Here a patch for this. CHICKEN_INSTALL_PREFIX overrides the bin, include
or share directories when generating the install scripts. Note that the
installed
egg-info files refer to the new directory as well, so this is not the same as
DESTDIR.
chicken-status + chicken-uninstall will list an
> Attached is a patch that adds an extra environment variable
> (CHICKEN_INSTALL_BINDIR) to specify an alternative directory for
> executables (please don't consider applying -- it only serves to
> illustrate the situation). I don't think it is enough, though. Maybe
> eggs will want to install do
Applied and pushed.
felix
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
> On 2017-05-15 9:24, felix.winkelm...@bevuta.com wrote:
> > I would like to elevate it to an official policy that patches that
> > break bootstrapping should only be pushed when there is a publicly
> > available snapshot tarball.
>
> That certainly makes sense to me.
>
> If there are no objecti
> Please note that you will need to use a chicken (or a
> boot-chicken) that includes the first commit in order to build this
> second one.
I would like to elevate it to an official policy that patches that
break bootstrapping should only be pushed when there is a publicly
available snapshot tarba
> I was filling in the "Module (chicken process)" wiki page for the new
> manual, and noticed something peculiar:
>
> current-process-id and parent-process-id are in (chicken process-context),
> but process-group-id and its related setter, and create-session are in
> (chicken process). This seems
> Hello hackers,
> here are some small patches that fix some small problems I found while
> playing around.
Nice - one suggestion: a common format for error messages with line-numbers
would
make it easier for tools to parse the msg and navigate to the location.
felix
_
Hi!
This patch removes the internal procedure "chicken-prefix" in eval.scm,
and thus any support for the CHICKEN_PREFIX environment variable.
Also, some old refrences to CHICKEN_INSTALL_PREFIX have been removed
from the documentation.
felix
From 00ed94a099f25e20b141a1e54f5fa0548e174517 Mon Sep
Hi!
As evhan suggested, this patch drops the "-all" option for chicken-status,
giving it thhe same view of the set of available eggs as is represented
by CHCIKEN_REPOSITORY_PATH. This is more consistent with what the
user sees. CHICKEN_INSTALL_REPOSITORY is still fully functional, but
needs to be
> Ubuntu-derived distributions now ship with /tmp mounted as noexec by
> default. This results in a chicken-install error that is difficult to
> diagnose by non-expert users. The remedy can be as simple as setting
> TMPDIR (but perhaps that should be prominently documented), an option
> that forces
Hi!
There was a bug in the linking-test section of tests/runtests.sh (fix pushed.(
The base64-installation problem I can't reproduce.
felix
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken
Hello!
The new egg-installation stuff is now in a state that seems to be basically
usable and I wonder how to go on with this, as it is a bit of a hassle to keep
this branch in sync with the C5 master.
Egg installation (for the basic set of eggs we currently have) seems to work
fine, including fu
> On Mon, Mar 27, 2017 at 08:37:05PM +0200, lemonboy wrote:
> > As promised here's the patch, sorry for the noise.
>
> I don't understand this code at all. Why does it (touch) and then
> scan the first expression again, and what does "escaped" mean exactly?
The second scan of "first" was incorre
> On Sat, Feb 25, 2017 at 06:13:48PM +0100, Peter Bex wrote:
> > However, I figured out that the real cause of #1309 is much, much deeper
> > and has to do with a nasty bug in ##sys#canonicalize-body: it invokes
> > "fini" as soon as it sees a non-pair. However, fini doesn't handle
> > expansions
Hi!
IIRC, all the module changes are not documented, yet, is this correct?
Would it be a good idea to start documenting these changes? Speaking only
for myself, I completely lost my grasp on what functionality is provided by
what modules
felix
_
> I'll tag version 1.0 of the compile-file egg once they've been applied,
> assuming they look OK.
Excellent. Could you add the egg also to the chicken-5-eggs repo?
felix
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongn
> On 2017-03-02 10:34, felix.winkelm...@bevuta.com wrote:
> > Is this for CHICKEN 5? If not, then we need a change request, as this is an
> > incompatible change.
>
> I think this, and in fact all changes that aren't strictly bug fixes for 4.12,
> should go into chicken-5 only from this point on.
Thanks - I pushed a fix.
felix
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Hello!
I've pushed a few changes regarding the new egg install and would be
happy about feedback regarding these changes:
* chicken-status + chicken-uninstall use exact matching by default (use -match
to use globbing)
* there are now 2 env vars:
CHICKEN_REPOSITORY_PATH: one or more direct
> On 2017-03-02 10:36, felix.winkelm...@bevuta.com wrote:
> > I can't recall whether we have settled on this, but having a "file"
> > and a "files" module strikes me and somewhat confusing.
>
> Right, it's my intention that we drop "files" once it (and posix) have
> been refactored into "file" and
I can't recall whether we have settled on this, but having a "file" and a
"files"
module strikes me and somewhat confusing.
felix
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Hi!
Is this for CHICKEN 5? If not, then we need a change request, as this is an
incompatible
change.
felix
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
> > Mario, would this help with Salmonella?
>
> Not sure if I undertand the proposal. You mean chicken-install would
> install eggs in the directory pointed by CHICKEN_REPOSITORY?
I would suggest to _lookup_ eggs (during loading + linking) from any
of the directories given in CHICKEN_REPOSITORY.
> On Thu, Feb 23, 2017 at 02:00:46PM +0100, felix.winkelm...@bevuta.com wrote:
> > Some time ago there was a strong interest in supporting mulitple local egg
> > repos (i.e. CHICKEN_REPOSITORY would specify a list of directories, each
> > of which may contain eggs). Would that allow dropping -prefi
> > * When a test in a depency fails, the installation process still continues,
> > should the whole operation abort?
>
> Is this related to the question ""-test" implies that all tests are
> executed ..."? I think the current behavior in C4 is nice: tests are
> only executed for the eggs given
> Exciting news! What would it take to get deployment working? In the
> past, I found it immensely useful to be able to distribute binary,
> particularly with Windows and Mac OS X users who are not likely to
> have a compiler installed, or a readily installable Chicken binary
> distribution.
Dep
Hello!
I have now a first prelininary version of the new egg installation tools
for CHICKEN 5 working, and before we go on, I'd like people to review
and reflect on the changes that have been made so far. I also need
some advice regarding a number of issues...
The branch is "chicken-5-new-egg-in
> I really hate playing this stupid game of whack-a-mole with header
> definitions (there seems to be no sane combination of definitions that
> will work on all OSes). Instead, I think it's better to just give in
> and add the --std=gnu99 on all platforms where we're using gcc and clang.
> I'd app
Hello!
I'm currently trying to implement the new egg-install for CHCIKEN 5
and if people like to contribute by testing this, I would be very grateful.
The branch is "chicken-5-new-egg-install", in the chicken repo. The main
"innovation" is a new egg description file format, that can be statically
> And here's another one, that adds C_likely() and C_unlikely() macros,
> a la the Linux kernel's likely() and unlikely(). These are simple
> wrappers for __builtin_expect() which tell the compiler which branches
> in a conditional expression are likely to be taken.
>
Signed off and pushed.
fe
> Hi all,
>
> I've been playing around a little bit with "perf" and Valgrind's
> cachegrind tool, and I noticed that the number of branch prediction
> misses can be reduced if the argvector reusing check can be hardcoded
> for cases where we know the size of the calling function's argvector.
>
>
> > That can still be done, and seems to me independent of -prefix. by
> > using salmonella like any other egg.
>
> I'm afraid I don't follow you here. Salmonella needs a way to install
> eggs using an empty local egg repository, otherwise the already
> installed eggs may prevent the detection of
> > I think it would. To truly test in a clean environment I would suggest to
> > use a fresh chicken installation for case 1 as well. Note that this can
> > be done by pure copying/hardlinking of files, assuming the user didn't
> > modify installed files.
I was talking nonsense here - of course s
> On Tue, 03 Jan 2017 21:35:46 +0100 felix.winkelm...@bevuta.com wrote:
>
> >> Salmonella relies on -prefix to install eggs into a fresh local egg
> >> repository. That's how it is able to catch dependency problems, for
> >> example.
> >
> > Shouldn't you use a separately built chicken insallatio
> Salmonella relies on -prefix to install eggs into a fresh local egg
> repository. That's how it is able to catch dependency problems, for
> example.
Shouldn't you use a separately built chicken insallation for that, with a
pristine egg repository for each run?
felix
> The question was actually related to C4, as the behavior of -prefix
> changed in 4.11 (see http://bugs.call-cc.org/ticket/1298 ).
Yes, that might be. The answer is still the same. It was a hack from the
beginning.
>
> Regarding C5, any idea on how to implement a tool like salmonella?
I don't
> Felix: what was the original intended behavior for -prefix, regarding
> handling of dependencies?
IIRC, it was just a hack for overriding the installation prefix, among other
crude methods (CHICKEN_PREFIX, or CHICKEN_INSTALL_PREFIX, or whatever,
I lost track...).
It should go, IMHO. No prefix-o
> I'm not sure what to do about #1293. We don't have a simple way
> of assigning unique object IDs, so some objects will "notice" they
> get moved by the GC and all objects will notice when they're mutated.
I don't really consider this a bug. It's a natural result of using eq? as
hash-table eleme
> Hi all,
>
> Attached is a pretty straightforward patch to fix #1144.
> The problem is that we're using "extension-information"
> while walking the egg list to see which eggs already exist.
> If extension-information returns a non-#f value, it will
> be removed from the list.
>
> When using -pre
Dear CHICKEN folks!
I wish all of you a very happy christmas.
felix
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
> On Sun, Dec 11, 2016 at 10:58:50PM +0100, felix.winkelm...@bevuta.com wrote:
> > I don't know, but reading what you wrote in the ticket ("... this will
> > require quite a bit of rework and hardcoding all defining forms into the
> > compiler (which we have to do already anyway, to make internal d
I don't know, but reading what you wrote in the ticket ("... this will
require quite a bit of rework and hardcoding all defining forms into the
compiler (which we have to do already anyway, to make internal defines
work)...") makes me cringe.
It's the responsibility of the defining forms to expand
> Hi all,
>
> I've taken a look at #1332. Attached are patches against master and
> CHICKEN 5 to fix keyword handling.
I would propose to change this only in 5, since this might break things (as
you hint at below).
> To avoid all these issues, I think it's simplest to just ignore the
> keyword
> But yeah, we might want to consider exposing the three version thingies
> (major, minor, binary) as procedures or constants from Scheme as well.
"chicken-version" returns this string, where the 4rd number already has a
different
meaning. So I would not throw this together with the exissting mea
> On Tue, Oct 4, 2016 at 4:00 AM, wrote:
>
> > > We could still get rid of the tagged pointer type. After some more
> >
>
>
> > > thought on the matter, I believe they're mostly worthless.
> >
> > "They" means tagged pointers? I agree.
> >
>
> I continue to disagree. Tagged pointers make it
> > A somewhat disturbing patch, but it does indeed simplify the
> > code.
>
> What's disturbing? The huge amount of changes?
So many hardcoded numbers, easy to get things wrong.
>
> > Having only one type bit lefft worries me a bit, though.
>
> We could still get rid of the tagged pointer ty
> On Mon, Aug 08, 2016 at 10:56:39PM +0200, Peter Bex wrote:
> > The attached patches add a custom type for bignums (first patch) and
> > custom types for ratnums/cplxnums (second patch). This reduces the
> > aforementioned C_s_a_i_times() pre-allocation from 40 to 29 words.
>
> Here's an updated
Signed off and pushed. Since Patch #1 didn't apply cleanly I just committed it
by
hand.
felix
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
> On Thu, Sep 29, 2016 at 01:49:47PM +0200, felix.winkelm...@bevuta.com wrote:
> > Hello!
> >
> > I'm currently trying to evaluate these patches and have a few questions:
> >
> > - If I understand correctly, a symbol must be explicitly persisted by
> > marking it using
> > "C_i_persist_symbo
Hello!
I'm currently trying to evaluate these patches and have a few questions:
- If I understand correctly, a symbol must be explicitly persisted by marking
it using
"C_i_persist_symbol", but that only seems to happen when assigning to a
global in
the evaluator, or when using "C_putpro
Hello!
The following two patches change the default colors in feathers to something
more neutral and fix an issue with the use of the source file search path:
running the debugger in a different directory didn't use the search path passed
with "-dir" correctly.
felix
From 12823ee908619fa7a32c
Hi!
Signed off and pushed.
felix
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
>
> Out of curiosity: any example where substring=? would be useful in
> practice?
Grep the egg repo, you will find some uses. But generally speaking, it's
somewhat difficult to come up with a metric of usefulness - the danger
being (as always) being blinded by our own limited experience.
Having
>
> Hello all,
>
> Sjamaan and Mario on the channel brought up an interesting issue with
> substring=?. The current semantics check only to the length of the
> shorter string, so:
>
> (and (substring=? "foo" "foobar") (substring=? "foobar" "foo")) => #t
>
>
> I submit that this behaviour is co
> On Tue, Aug 09, 2016 at 10:31:54AM +0200, felix.winkelm...@bevuta.com wrote:
> > > All in all, I think these changes are worthwhile but for the caveat
> > > that it results in us having NO MORE reserved type tags left! In
> > > fact, the complete change is only possible because we dropped the
>
> My main concern, after giving it some more thought, is that you can't
> easily make the FFI check the pointer type, unless you enforce that
> pointer tags are somehow either compile-time constants, or also stored
> in some global that's directly accessible to the FFI. There should be
> a low-ove
> All in all, I think these changes are worthwhile but for the caveat
> that it results in us having NO MORE reserved type tags left! In
> fact, the complete change is only possible because we dropped the
> SWIG pointer type; before that we only had two reserved types left.
> I don't see an easy w
> On Mon, Jul 18, 2016 at 03:59:52PM +0200, felix.winkelm...@bevuta.com wrote:
> > > I think it would be good for chicken's spread and adoption in the scheme
> > > world if its install system supported this case of multi-implementation
> > > libraries, where the chicken-specific files can all be in
> I think it would be good for chicken's spread and adoption in the scheme
> world if its install system supported this case of multi-implementation
> libraries, where the chicken-specific files can all be in a
> subdirectory. To that end, I propose that some declaration could be
> added to .relea
> The limit probably was put in there for a
> reason. Maybe Felix can enlighten us here?
Well, performance, obviously - you don't want to iterate over all elements
of a vector just to get a hash.
felix
___
Chicken-hackers mailing list
Chicken-hacker
501 - 600 of 1063 matches
Mail list logo
