Claus Reinke wrote:
> Btw, is there a way to reset the opengl system to a sane state in
> software? Or are there some invalid assumptions about default
> state in the other examples?
If OpenGL is getting "stuck" in a non-functional state, that indicates
a bug in the
;t ignore SIGINT/SIGQUIT in the child, but I
> can fix that if necessary.
I'm not sure how much it matters; system() isn't really of much use
for "real" programs anyhow.
--
Glynn Clements <[EMAIL PROTECTED]>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
t the child restores the handlers to their state upon
entry.
> I realise this doesn't address the library design issues you raised, but
> as you pointed out there doesn't seem to be a good platform-independent
> solution here.
Yes; any programs which perform non-trivial process m
which
might have been corrupted is inadvisable.
Also, at_exit() isn't standard. atexit() is ANSI C, but that is only
supposed to be called for normal termination (exit() or return from
main()), not for _exit() or fatal signals.
--
Glynn Clements <[EMAIL PROTECTED]>
eant to be persistent. For the same reason, the
OS doesn't delete upon termination any files which the process
created.
--
Glynn Clements <[EMAIL PROTECTED]>
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
t code in the case of normal termination, but complicating the
handling of abnormal termination.
--
Glynn Clements <[EMAIL PROTECTED]>
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ExitCode invariably throws an exception.
>
> Or do I misunderstand something?
No, that seems correct.
Although, depending upon the OS, setting SIGCHLD to SIG_IGN may cause
processes to be reaped automatically (i.e. not become zombies), so
that's a possible alternativ
() (or
Maybe (IO ()), where Nothing is shorthand for Just $ return ()) which
would be executed between the fork and the exec on Unix and ignored on
Windows. AFAICT, that would expose the full functionality available on
Unix without interfering with Windows usage or adding complexity.
--
Glynn
child, but then execve() will reset them
to SIG_DFL, as the handler functions won't exist after the execve().
--
Glynn Clements <[EMAIL PROTECTED]>
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
r in their handling of errors. waitForProcess will throw an
exception if waitpid() indicates any error (except EINTR, where it
just retries the waitpid() call), whereas getProcessExitCode will
return Nothing. Both will throw an exception if the process terminated
on a signal.
--
Glynn Clements &
ver aborted]: cannot write /cvs/CVSROOT/val-tags: Read-only file system
--
Glynn Clements <[EMAIL PROTECTED]>
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Yes. The new* functions allocate the memory with malloc, and you have
to free it yourself. OTOH, the with* functions allocate the memory
with alloca, and it is freed automatically.
Also, a ForeignPtr includes a finaliser which will free the data
automatically when it is no longer referenced.
--
er which processed connections sequentially wouldn't be of much
practical use (and a one-shot server probably wouldn't even be of use
for "toy" programs).
--
Glynn Clements <[EMAIL PROTECTED]>
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
more that Network.recvFrom looks like
someone was hell-bent on producing a complement to Network.sendTo,
regardless of the benefit (or even sanity) of doing so.
Actually, if someone desperately wants a complement to sendTo, a
recvTo function would be more useful than recvFrom. I.e. connect to a
server and read data until the server closes the connection (usable
with services such as systat, netstat, daytime etc).
Similarly, sendFrom (i.e. accept a connection and send data) would be
just as useful as recvFrom.
--
Glynn Clements <[EMAIL PROTECTED]>
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
n Network, sClose should be in
there too. That would at least provide an API which is usable for the
simplest programs.
OTOH, the core problem with Network.recvFrom is essentially that it
appears to be a misguided attempt to provide a symmetric counterpart
to Network.sendTo. While the low-level s
lly, it will throw an exception if it can't get the client's
hostname (which is quite possible; many IP blocks don't have PTR
records, particularly the private blocks, e.g. 192.168.*).
--
Glynn Clements <[EMAIL PROTECTED]>
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
.
> * is there a general way to get ghci out of a state where
> it's got stuff open on inaccessible sockets?
The solution to most problems with the Network module is not to use
the Network module, but to use Network.Socket instead.
--
Glynn Clements <[EMAIL PROTECTED]>
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
the "struct sock",
and getsockopt reads it from there, although I haven't checked whether
specific protocols honour those settings.
--
Glynn Clements <[EMAIL PROTECTED]>
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://
ote: neither socketOptLevel nor packSocketOption are exported from
Network.Socket, so you would need to copy those (or just pass a pair
of integers instead of the SocketOption).
> Am I even supposed to set them, or is there a better way to
> specify gener
I don't have glibc 2.3 here, but presumably __ctype_b has changed in
an incompatible manner (maybe there are more than 16 flags in 2.3, in
which case an unsigned short would no longer be sufficient).
--
Glynn Clements <[EMAIL PROTECTED]>
_
so anything
which uses X is affected.
+ Anything which supports the "~user" syntax to refer to a specific
user's home directory will need to use getpwnam().
+ Anything which needs to translate between UIDs and usernames will
need to use getpwnam() and/or getpwuid().
+ Etc
ant any processing, the correct solution is to bypass
the shell altogether, *not* to attempt to subject the string to an
inverse transformation in the hope that the shell will eventually end
up passing the desired argv[i] to the called program.
--
Glynn Clements <[EMAIL PROTECTED]>
__
sed
by glibc's malloc(). Also, getrlimit(RLIMIT_RSS) is probably more
relevant for your purposes.
--
Glynn Clements <[EMAIL PROTECTED]>
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
PosixProcEnv.lhs (which is
where I'd expect it to live).
As for the amount which the OS might be willing to allocate to your
process at any given point in time, that information probably isn't
available by any means.
--
Glynn Clements <[EMAIL PROTECTED]>
_
t; (c_execve s arg_arr env_arr)
IOW:
search env function
False Nothing execv
TrueNothing execvp
False Just _ execve
TrueJust _ execvpe [*]
[*] execvpe() isn't a standard library function; i
f child processes (which they don't bother to reap) and then
terminate shortly thereafter (a process whose parent has terminated is
"adopted" by the init process, which can be relied upon to reap it
when it terminates).
--
Glynn Clements <[EMAIL PROTECTED]>
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ated but the parent (your program) hasn't called wait/waitpid
(the Haskell interface is getProcessStatus, getProcessGroupStatus or
getAnyProcessStatus).
--
Glynn Clements <[EMAIL PROTECTED]>
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
y = unsafePerformIO $ newIORef 0
Due to optimisation, x any y may end up referring to the same IORef.
In short: Haskell assumes referential transparency; if you break it,
all bets are off.
--
Glynn Clements <[EMAIL PROTECTED]>
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
t might use a different byte order to a 32-bit int (so says
a comment in glibc's ).
--
Glynn Clements <[EMAIL PROTECTED]>
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
x) or TMP (Windows), so you can have
these files stored in a private directory.
--
Glynn Clements <[EMAIL PROTECTED]>
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
. It isn't suitable for implementing a
"commodity" protocol which can be used for communication between
different architectures.
--
Glynn Clements <[EMAIL PROTECTED]>
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
sn't work either.
>
> Surely someone has done this at some point...or is it even possible
> (please say it is)...
For Unix, use Posix.handleToFd to get a descriptor, then fdopen() (in
C, or write a foreign import) to get a FILE*.
Also, don'
Therefore, I need to be able to
> coerce my binary data buffer to a String.
Correct. IOW, lots of messing around with ord and chr and either
mod/div or the Bits library.
--
Glynn Clements <[EMAIL PROTECTED]>
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
s, which
isn't necessarily the same one that was used in the linking step. The
-R switch will cause the runtime linker to search specified directory
before the "normal" library directories (e.g. /usr/lib).
--
Glynn Clements <[EMAIL PROTECTED]>
__
27;t
> > immediately obvious before reading the docs or using C-h m (or C-h b).
>
> What is "fume"? C-h m did not reveal any surprises to me.I only use the
> recommended setup:
AKA "func-menu.el":
`function-menu' is
technically possible, you may not always be able to determine
exactly how to reopen it, e.g. if it was a file, what was its
pathname? However, for the specific case of a terminal on Unix, you
can use Posix.getTerminalName; re-opening that will typically work.
--
Glynn Clements <[EMAIL PROTECTED]>
__
; exists
-- for each type constructor (put it at the top level, and annotate the
-- corresponding definition with a @NOINLINE@ pragma).
If you use:
fooTc = mkTyCon "Foo.Foo"
instance Typeable Foo where
typeOf _ = mkAppTy fooTc []
or compile with "-O"
applies to all reads.
Either of these approaches will confuse some set of users. Anything
other than disabling buffering altogether will confuse users who are
completely unaware of buffering.
--
Glynn Clements <[EMAIL PROTECTED]>
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
typeOf _ = mkAppTy fooTc []
--
Glynn Clements <[EMAIL PROTECTED]>
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
the xthread_*
macros.
I have no idea as to the situation on Windows.
--
Glynn Clements <[EMAIL PROTECTED]>
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
40 matches
Mail list logo
