Re: [PATCH] Fix get-bytevector-all read redundant eof

[Nala Ginrut]

On Thu, 2013-03-14 at 17:30 +0800, Nala Ginrut wrote:
> Attached the patch to fix get-bytevector-all.
> You may check it like this:
> (get-bytevector-all (current-input-port))
> 
> And try to input then type ctrl+d, the current implementation needs you
> type ctrl+d twice.
> 
> Regards.


Sorry, but I realized that this patch only fixed when you type ctrl+d in
the beginning. But if you input something, the problem is still there.
I'll look deeper.

Re: Help required with exporting and using GOOP generics

[Brent Pinkney]

On 15/03/2013 02:11, dsm...@roadrunner.com wrote:

 Mark H Weaver  wrote:

The proper solution is as follows:

* Every generic function must be defined (using 'define-generic') and
   exported from one (and only one) module.

* Every module that uses a generic function, or adds a method to it (and
   that includes slot accessors), must first import the generic function
   from the (one) module that exports it.

Think of a generic function as a normal procedure that contains an
internal table of methods.  Like any other procedure, there's a single
module that defines it and exports it.  The fact that some modules add
methods to these internal tables does not mean that it is appropriate to
export the procedure from those other modules.

Thanks Mark.  Very concisely put.


Really ?

How does that work in an environment where you are using third party 
libraries, lice srfi, ice-9, guile-lib, etc as well as your own code.


How could one possibly ensure that the other libraries export say 
"format" correctly - perhaps they are purists and not even aware of the 
goops modules.


I think guile has it backwards here - goops must not break quiles 
modules when someone imports a guile generic.



Thanks

Brent

Core dump when throwing an exception from a resumed partial continuation

[Brent Pinkney]

Hi,

I am using partial continuations to resume a computation when an 
external system returns with an answer.

I am using (call-with-prompt ...) and (abort-to-prompt)

When I resume the continuation in another thread, all works perfectly 
UNLESS the continued execution throws and exception.

Then guile exits with a core dump.

By contrast if I resume the continuation in the same thread and then 
throw and exception all works as expected.


Is this a known issue?

All assistance welcomed.


Thanks

Brent

Re: Help required with exporting and using GOOP generics

[Mark H Weaver]

Mark H Weaver  wrote:
> The proper solution is as follows:
>
> * Every generic function must be defined (using 'define-generic') and
>   exported from one (and only one) module.
>
> * Every module that uses a generic function, or adds a method to it (and
>   that includes slot accessors), must first import the generic function
>   from the (one) module that exports it.
>
> Think of a generic function as a normal procedure that contains an
> internal table of methods.  Like any other procedure, there's a single
> module that defines it and exports it.  The fact that some modules add
> methods to these internal tables does not mean that it is appropriate to
> export the procedure from those other modules.

Brent Pinkney  wrote:
> How does that work in an environment where you are using third party
> libraries, lice srfi, ice-9, guile-lib, etc as well as your own code.

I'm sorry, I don't understand what you mean here.

> How could one possibly ensure that the other libraries export say
> "format" correctly - perhaps they are purists and not even aware of
> the goops modules.

'format' is not a generic function.  What does that have to do with this
discussion?

> I think guile has it backwards here - goops must not break quiles
> modules when someone imports a guile generic.

Again, I don't understand.  What do you mean by "break guile's modules"?
Can you please elaborate?

Thanks,
 Mark

Re: [PATCH] Fix get-bytevector-all read redundant eof

[Mark H Weaver]

Nala Ginrut  writes:

> On Thu, 2013-03-14 at 17:30 +0800, Nala Ginrut wrote:
>> Attached the patch to fix get-bytevector-all.
>> You may check it like this:
>> (get-bytevector-all (current-input-port))
>> 
>> And try to input then type ctrl+d, the current implementation needs you
>> type ctrl+d twice.
>> 
>> Regards.
>
>
> Sorry, but I realized that this patch only fixed when you type ctrl+d in
> the beginning. But if you input something, the problem is still there.
> I'll look deeper.

FWIW, I suspect you'll have to dig fairly deep to fix this properly.
AFAIK, the ports code was not designed to ensure that exactly one EOF is
reported to the user for each EOF returned by the kernel.  I hope to
look into this soon (possibly before 2.0.8), as part of my investigation
of .

Thanks,
  Mark

Re: Core dump when throwing an exception from a resumed partial continuation

[Andy Wingo]

Hi,

On Fri 15 Mar 2013 22:01, Brent Pinkney  writes:

> I am using partial continuations to resume a computation when an
> external system returns with an answer.
> I am using (call-with-prompt ...) and (abort-to-prompt)
>
> When I resume the continuation in another thread, all works perfectly

Neat :)

> UNLESS the continued execution throws and exception.
> Then guile exits with a core dump.

That's not good!  Can you work up a short test case?

Thanks,

Andy
-- 
http://wingolog.org/

Re: Help required with exporting and using GOOP generics

[Mark H Weaver]

Brent Pinkney  writes:
> How does that work in an environment where you are using third party
> libraries, lice srfi, ice-9, guile-lib, etc as well as your own code.

Okay, I have a guess about what you meant here.  Suppose two
independently developed modules add methods to generics with the same
name.  How can they arrange to export the generic from a single module?
This is the heart of the issue.

The problem is, how does Guile know that these two generics with the
same name *should* be merged together?  Maybe they have completely
different semantics.

For example, suppose a curses-based display module defines a "draw"
generic function, and adds methods to it for the standard Scheme data
types such as strings and lists.  Now suppose an unrelated OpenGL
display module defines its own "draw" generic function, and adds methods
for the same Scheme data types.

It would obviously be bad if Guile assumed that these were the same
generic function, just because they have the same name.  And yet
avoiding such collisions would require giving generic functions long
names, and the crossing one's fingers and hoping that no one else used
the same name, just like in the bad old days of Lisps based on
dynamically-scoped variables.

On the other hand, if you know that two generics from independently
developed modules should be merged, then you can make that happen using
the 'merge-generics' stuff.  However, it's best to avoid this way of
doing things when feasible.

In particular, the practice of letting each module in your project
automatically define fresh generics (and then merging these generics
together while importing the modules) has a serious problem: it means
that each module ends up with generics that only work on the classes
that it *directly* imported.  In many cases this is not sufficient.

  Mark

Re: [PATCH] Fix get-bytevector-all read redundant eof

[Nala Ginrut]

On Fri, 2013-03-15 at 17:20 -0400, Mark H Weaver wrote:
> Nala Ginrut  writes:
> 
> > On Thu, 2013-03-14 at 17:30 +0800, Nala Ginrut wrote:
> >> Attached the patch to fix get-bytevector-all.
> >> You may check it like this:
> >> (get-bytevector-all (current-input-port))
> >> 
> >> And try to input then type ctrl+d, the current implementation needs you
> >> type ctrl+d twice.
> >> 
> >> Regards.
> >
> >
> > Sorry, but I realized that this patch only fixed when you type ctrl+d in
> > the beginning. But if you input something, the problem is still there.
> > I'll look deeper.
> 
> FWIW, I suspect you'll have to dig fairly deep to fix this properly.
> AFAIK, the ports code was not designed to ensure that exactly one EOF is
> reported to the user for each EOF returned by the kernel.  I hope to
> look into this soon (possibly before 2.0.8), as part of my investigation
> of .
> 

Yes, I tried the bug-demo code of dwheeler, and found that EOF seems was
eaten in somewhere. 
I read the code on the calling-tree of scm_peek_char, but hardly find
the problem related. 
Maybe it's something about the 'port' implementation?

> Thanks,
>   Mark