Mike Gran writes:
> If there were a go archive, I could finally make a port to
> MS-DOS because I could ignore the 8.3 filesystem limitation. ;-)
A much simpler solution would be to modify the logic near the top of
`try-module-autoload' in boot-9.scm, which translates a module name to a
pathname
Andy Wingo writes:
> On Tue 03 Jan 2012 22:44, Mark H Weaver writes:
>
>> If this single file is to be built only during the package build
>> process, and never modified after that, then it should be super-easy to
>> invent your own little homebrew format.
>
> Indeed. It would be nice to use EL
On Tue 03 Jan 2012 22:44, Mark H Weaver writes:
> If this single file is to be built only during the package build
> process, and never modified after that, then it should be super-easy to
> invent your own little homebrew format.
Indeed. It would be nice to use ELF, though. I'd like to change
>> There are some theoretical corner cases where it could be useful.
>> Don't know if these would ever occur in practice.
>> - Systems that don't use a Unix-like filesystem heirarchy
>
> I also don't see how Unix-like filesystem semantics affect this
> question.
If there were a go archive, I
Mike Gran writes:
>> From: Mark H Weaver
>
>> What is the advantage of including our own little read-only filesystem,
>> when every OS already provides this functionality? Is it really
>> significantly easier to install 3 files than to install 300?
>>
>> Admittedly, I can see how it might make
> From: Mark H Weaver
> What is the advantage of including our own little read-only filesystem,
> when every OS already provides this functionality? Is it really
> significantly easier to install 3 files than to install 300?
>
> Admittedly, I can see how it might make a psychological difference
Mike Gran writes:
> The libguile would be modified so that the .iso or .tar file would
> never be unpacked. Guile would look inside the .tar or .iso for the
> compiled .go files.
What is the advantage of including our own little read-only filesystem,
when every OS already provides this functio
> From: Ludovic Courtès
> OK, but back to the example above, you wouldn’t want Lilypond’s tarball
> to contain these binaries, would you?
For Lilypond on Win32, where the culture is to download
compiled binaries, I'd want to be able to provide a download location
for a pre-compiled Win7 x86 lib
Hi Mike!
Mike Gran skribis:
>> From: Ludovic Courtès
> > Hi Mike!
>>
>> Mike Gran skribis:
>>
>>> It'll be fun to try to minimize it down to just
>>> the guile executable, libguile-*, and a scheme archive file. And it
>>> might help with distribution of prebuilt versions.
>>
>> Are you
> From: Ludovic Courtès
> Hi Mike!
>
> Mike Gran skribis:
>
>> It'll be fun to try to minimize it down to just
>> the guile executable, libguile-*, and a scheme archive file. And it
>> might help with distribution of prebuilt versions.
>
> Are you saying that, say, Lilypond’s tarball woul
Hi Mike!
Mike Gran skribis:
> It'll be fun to try to minimize it down to just
> the guile executable, libguile-*, and a scheme archive file. And it
> might help with distribution of prebuilt versions.
Are you saying that, say, Lilypond’s tarball would contain libguile.so
and the .go files? (I
On Wed, 2011-12-21 at 08:03 -0800, Mike Gran wrote:
> To keep it GNU, I looked around to see what library-style GNU
> solutions exist for treating an archive file like a filesystem.
> Oddly, no good documented (L)GPL GNU options dealing with tar, cpio,
> pax, or 'ar' in an API way. But, there is
Noah Lavine writes:
> Hello,
>
>> To keep it GNU, I looked around to see what library-style GNU
>> solutions exist for treating an archive file like a filesystem.
>> Oddly, no good documented (L)GPL GNU options dealing with tar, cpio,
>> pax, or 'ar' in an API way. But, there is a solution for .
Hello,
> To keep it GNU, I looked around to see what library-style GNU
> solutions exist for treating an archive file like a filesystem.
> Oddly, no good documented (L)GPL GNU options dealing with tar, cpio,
> pax, or 'ar' in an API way. But, there is a solution for .iso
> files: libiso9660 from
On Wed 21 Dec 2011 11:03, Mike Gran writes:
>> A while ago I was looking at the idea of minimizing the number of
>> files needed to ship Guile as a dependency. At the time, I thought
>> that one could retool the build so that it produced
>> - a tar.gz of the distributable header files
>> - libgu
> From: Mike Gran
>
> Hi-
>
> Re point 2: hard to distribute.
>
> A while ago I was looking at the idea of minimizing the number of
> files needed to ship Guile as a dependency. At the time, I thought
> that one could retool the build so that it produced
> - a tar.gz of the distributable head
Hi Noah,
On Mon 19 Dec 2011 23:32, Noah Lavine writes:
> I was thinking about it though, and I think there is another thing
> that is causing a lot of this "bloat": all of the Scheme modules we
> are adding.
Do you really think so? It's more installed size, but it doesn't
affect runtime speed,
This is an interesting point.
I was thinking about it though, and I think there is another thing
that is causing a lot of this "bloat": all of the Scheme modules we
are adding.
There is a tension here, because having lots of modules is very
important for using Guile as a language to write program
18 matches
Mail list logo