unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: Andy Wingo <wingo@pobox.com>
To: Jan Schukat <shookie@email.de>
Cc: 15160-done@debbugs.gnu.org
Subject: bug#15160: Is --disable-posix excluding too much?
Date: Tue, 21 Jun 2016 11:41:06 +0200	[thread overview]
Message-ID: <87mvme3mml.fsf@pobox.com> (raw)
In-Reply-To: <5215F58E.3080901@email.de> (Jan Schukat's message of "Thu, 22 Aug 2013 13:27:10 +0200")

Hi!

--disable-posix is intended to be a size reduction thing, not
necessarily a portability hack.  Guile should build on MinGW with POSIX
enabled; if it doesn't that's a different bug :) When POSIX support is
enabled we should simply compile out features that aren't detected on
the platform.  For that reason it doesn't make sense to take more things
out from under --disable-posix.

Regards,

Andy

On Thu 22 Aug 2013 13:27, Jan Schukat <shookie@email.de> writes:

> Hello, it's been a while since I wrote here. Took me a while to figure
> out how to best tackle the native type vector alignment thing
> properly. Ended up writing my own binary data formats and the smaller
> dynamically created ones get their own SCM_DEFINE c constructors. The
> compiled guile byte-vector format isn't too efficient anyway atm. Once
> true elf-binaries are generated I guess that is different, since they
> can be directly and natively embedded. When that comes along I might
> look into it again. It's always good to consolidate and unify code
> that can be, to reduce redundancy.
>
> Anyway, new issues arise. Using a scripting language somewhat portably
> for non-performance critical management tasks is pretty normal right?
> One of the prime uses.
> So, I'm walking directory trees now, and occasionally need to copy a
> file. But copy-file is not available when --disable-posix is
> configured. There are lot's of possible workarounds. Copying files in
> different languages is first semester programming assignments. The
> point is: a high level language shouldn't make you do this. File
> systems and paths are pretty much the same on all platforms guile runs
> on. And that's the the interface to the function: two paths. There is
> no reason to to not have that function everywhere.
>
> Similarly for chdir. You can work around it, and the file tree walking
> functions make it mostly unnecessary. But I see no reason to leave it
> out. Any system guile runs on knows paths.
>
> (oh, and --disable-posix is necessary to compile on/for windows/mingw,
> the cost of portability)
>
> Regards
>
> Jan Schukat





      reply	other threads:[~2016-06-21  9:41 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-22 11:27 bug#15160: Is --disable-posix excluding too much? Jan Schukat
2016-06-21  9:41 ` Andy Wingo [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mvme3mml.fsf@pobox.com \
    --to=wingo@pobox.com \
    --cc=15160-done@debbugs.gnu.org \
    --cc=shookie@email.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).