No even if you have cross module inlining you will still be able to tell i
a module will allow inlining or not else you will break quite a lot of nice
scheme idioms.
This means that this is indeed future proof.
On Wed, Feb 12, 2020 at 10:50 PM Linus Björnstam <
linus.bjorns...@veryfast.biz>
On 2020-02-12 21:14, Stefan Israelsson Tampe wrote:
I saw from the stacktrace that the repo uses a not available module. I
dried to fix that and missed pushing it. I agave now pushed so you
could try to pull and compile again
Yep, now it works.
guile-persist builds on commit
Le mercredi 12 février 2020 à 06:04 -0800, Matt Wette a écrit :
>
> On 2/12/20 5:54 AM, Matt Wette wrote:
> > Here is my solution. What do you think? If $prefix is the same
> > as
> > used to build guile
> > then I use the directories from $guile. Otherwise, I use the
> > default. This now
If guile ever gets cross-module Inlining in even the simplest form, this will
break. This kind of inlining is probably the most secure one to rely on ever
(my for loops rely on it, for example). A more future proof option is maybe to
(set! ...) A variable within the same module, which makes it
On 2020-02-12 18:18, Stefan Israelsson Tampe wrote:
you should update the guile-persist repo and also stis-parser, there
was some cond-expand issues in those as well
Ok. I tried that. stis-parser now built fine on commit
8d49401e238ae703a466b5b98d3068e4fa974f2c
but guile-persist failed on
Hi,
Here is a repository for enabling or hindering aggressive inlining of
guile-3.0 code. We may use it for discussions of how one could do these
things. Perhaps wingo will change the compiler, but I got the instruction
to code around it and this tool is what I ended up with.
Hi all,
Current guile inlines even variables exposed in the module interface, and I
understand that we must live with that and code around it. So here is a few
tips how to mitigate it.
The simplest way is to put this definition in a module:
(define-module (syntax
On 2020-02-12 10:59, Stefan Israelsson Tampe wrote:
no code for module (persist persistance)
can you use (persist persistance) e.g. from the guile shell,
(use-modules (persist persistance) )
Nope, that gives the same error. I had some issue when compiling the
stis-parser and/or
On 2/12/20 5:54 AM, Matt Wette wrote:
Here is my solution. What do you think? If $prefix is the same as
used to build guile
then I use the directories from $guile. Otherwise, I use the
default. This now works on
ubuntu and guix.
CorrectIon: "directories from $guile" means from paths
Hi All,
Over the last year I have been dealing with issues getting a
configure.ac put together
for my guile app. It needs to install .scm and .go files into the place
guile expects to
see them: (%site-ccache-dir) and %load-path. If I compile for my
ubuntu system then
the installed go
This is a good idea
On Tue, Feb 11, 2020 at 11:28 PM John Cowan wrote:
> Please document the binary format so that it is possible to write code in
> non-Guile (other Schemes or anything else) that can interoperate with it.
>
> On Tue, Feb 11, 2020 at 5:16 PM Stefan Israelsson Tampe <
>
You might want to compress it with gzip else as a binary format for sending
it it should be good.
On Tue, Feb 11, 2020 at 11:34 PM Zelphir Kaltstahl <
zelphirkaltst...@posteo.de> wrote:
> Hi Stefan!
>
> Would this be a good option for a binary format for transmission of data
> over network, or
no code for module (persist persistance)
can you use (persist persistance) e.g. from the guile shell,
> (use-modules (persist persistance) )
...
/Stefan
On Wed, Feb 12, 2020 at 10:18 AM david larsson
wrote:
> On 2020-02-11 21:57, Stefan Israelsson Tampe wrote:
> > This error is fixed in
On 2020-02-11 21:57, Stefan Israelsson Tampe wrote:
This error is fixed in repository
/Stefan
Thanks. That solved that part. Now Im getting this error on make:
(commit 226d33163e7f1e305c0b6e2ada37209513377dff)
--
Makefile:1390: warning: overriding recipe for target
14 matches
Mail list logo
