headers
Thomas Russ | 1 Nov 2003 02:23
Picon
Favicon

Re: OS X Priorities for MCL


On Friday, October 31, 2003, at 02:26  PM, james anderson wrote:

>> 2)  Better exception catching.
> i wonder what you can expect in this regard.
>
> on one hand one might think 'well c can do it', but on the other hand, 
> although one can always attach mcl to gdb and have it trap your 
> addressing errors, when i've resorted to that, it's been because i've 
> done something unnatural like trash the stack. at which point i've 
> never been in a much better a position to interpret the state in gdb 
> than to interpret the normal stack dumps.
>
> ? what kind of support are you looking for?

Well, I would like it not to crash.  That way I might have some chance 
to at least see which function blew up.  I realize that this may not be 
practical, but I have seen other lisps do this on Unix, so it may be 
possible...  I also realize that the place where something gets an 
address error may not be close to where the error was introduced, but 
when the entire environment exits, it's really tough to debug.

For now, I just make sure that there are CHECK-TYPE assertions in the 
MCL code, so that I also don't have my workspace blow up if I 
accidentally type an integer instead of a float when calling a function 
from the Listener.

(Probably too much detail, but this is running code that is generated 
from our own Stella language, so adding the type checks isn't too 
difficult to arrange, although it does sort of defeat the purpose of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Takehiko Abe | 1 Nov 2003 07:05
Gravatar

Re: So, does MCL work in Panther (10.3)

Alexander Repenning wrote:

> >I would add - switch to Carbon Events.
> 
> definitely: getting rid of the CFM part of Carbon CFM
> 

If I'm not mistaken, WaitNextEvent is not CFM specific.

I don't see any compelling reason to replace MCL's current
dispatching mechanism with carbon events.

Carbon events and MCL's WaitNextEvent based dispatching
can coexists (and it actually does already). MCL users
don't have to worry about them because, for instance,
whether view-click-event-handler is called through WNE
or carbon events is irrelevant. Either way, most of us
wouldn't notice the difference. If anyone needs to handle
events not availble through WNE, he can install a carbon
event handler. I already use them to handle TSM events.

Yet, removing WNE entirely is a lot of work. I'd like to
see something else comes first.
Permalink | Reply | 19 comments |
headers
Raffael Cavallaro | 1 Nov 2003 15:47
Picon

Re: So, does MCL work in Panther (10.3)


On Nov 1, 2003, at 1:05 AM, Takehiko Abe wrote:

> Carbon events and MCL's WaitNextEvent based dispatching
> can coexists (and it actually does already). MCL users
> don't have to worry about them because, for instance,
> whether view-click-event-handler is called through WNE
> or carbon events is irrelevant.

Not if you want your processes to continue to run while the mouse is 
down, or a menu is down.

MCL needs to move to Carbon Events at a minimum.

Raf

Raffael Cavallaro, Ph.D.
raffaelcavallaro@...
Permalink | Reply | 17 comments |
headers
Lawrence Au | 1 Nov 2003 17:29
Picon

connecting to DBs and SOAP


     I'm putting together a demo of a bridge
between databases and XML ontologies;
I need to connect to SQL databases.  Has anybody created
  ODBC, SOAP or XML interfaces for MCL?

-- Lawrence
Permalink | Reply | 1 comment |
headers
Gary Byers | 1 Nov 2003 22:37
Favicon

Re: OS X Priorities for MCL

>
> Date: Fri, 31 Oct 2003 17:23:23 -0800
> From: Thomas Russ <tar@...>
> Subject: Re: OS X Priorities for MCL
>
> On Friday, October 31, 2003, at 02:26  PM, james anderson wrote:
>
> >> 2)  Better exception catching.
> > i wonder what you can expect in this regard.
> >
> > on one hand one might think 'well c can do it', but on the other hand,
> > although one can always attach mcl to gdb and have it trap your
> > addressing errors, when i've resorted to that, it's been because i've
> > done something unnatural like trash the stack. at which point i've
> > never been in a much better a position to interpret the state in gdb
> > than to interpret the normal stack dumps.
> >
> > ? what kind of support are you looking for?
>
> Well, I would like it not to crash.  That way I might have some chance
> to at least see which function blew up.  I realize that this may not be
> practical, but I have seen other lisps do this on Unix, so it may be
> possible...  I also realize that the place where something gets an
> address error may not be close to where the error was introduced, but
> when the entire environment exits, it's really tough to debug.
>

I think that there are a couple of alternate approaches to otherwise
unhandled exceptions that could be taken:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alice Hartley | 1 Nov 2003 22:16

Re: So, does MCL work in Panther (10.3)

>On Nov 1, 2003, at 1:05 AM, Takehiko Abe wrote:
>
>> Carbon events and MCL's WaitNextEvent based dispatching
>> can coexists (and it actually does already). MCL users
>> don't have to worry about them because, for instance,
>> whether view-click-event-handler is called through WNE
>> or carbon events is irrelevant.
>
>Not if you want your processes to continue to run while the mouse is 
>down, or a menu is down.
>

The issue of allowing process scheduling to continue reliably while the
mouse is down or menu is down is high priorty for us.
Permalink | Reply | 0 comments |
headers
Gary King | 2 Nov 2003 03:27
Picon
Favicon

Re: connecting to DBs and SOAP

As far as XML goes, I've heard of several. Wilbur 
(http://wilbur-rdf.sourceforge.net/) is the one I've heard the most 
about...

On Saturday, November 1, 2003, at 11:29 AM, Lawrence Au wrote:

>
>     I'm putting together a demo of a bridge
> between databases and XML ontologies;
> I need to connect to SQL databases.  Has anybody created
>  ODBC, SOAP or XML interfaces for MCL?
>
> -- Lawrence
>
>
--

-- 
Gary Warren King, Lab Manager
EKSL East, University of Massachusetts * 413 577 0176

"... we have to recognise that the poor are an asset, hardworking and 
decent people. But with policies that discourage them, how do we expect 
them to improve their lot?"
-- Dr Anna Tibaijuka, The executive director of UN-Habitat
Permalink | Reply | 0 comments |
headers
Takehiko Abe | 2 Nov 2003 06:02
Gravatar

Re: So, does MCL work in Panther (10.3)

Raffael Cavallaro wrote:

> > On the other hand there really is nothing (with very few exception) 
> > that cannot be done in Carbon.
> 
> True of Carbon using Carbon Events. Not true of Carbon CFM. 
> Unfortunately, Digitool has chosen Carbon CFM, which means we *cannot* 
> use the following:
> 
> 1. Application Bundles.

Sorry, I cannot believe this one either. Where did you get
the idea?
Permalink | Reply | 0 comments |
headers
Takehiko Abe | 2 Nov 2003 05:57
Gravatar

Re: So, does MCL work in Panther (10.3)

Raffael Cavallaro wrote:

> > Carbon events and MCL's WaitNextEvent based dispatching
> > can coexists (and it actually does already). MCL users
> > don't have to worry about them because, for instance,
> > whether view-click-event-handler is called through WNE
> > or carbon events is irrelevant.
> 
> Not if you want your processes to continue to run while the mouse is 
> down, or a menu is down.

You keep suggesting that processes would run unblocked
automagically once event dispatching is done entirely through
carbon events. How is that so??
Permalink | Reply | 16 comments |
headers
Raffael Cavallaro | 3 Nov 2003 03:50
Picon

Re: So, does MCL work in Panther (10.3)


On Nov 1, 2003, at 11:57 PM, Takehiko Abe wrote:

> You keep suggesting that processes would run unblocked
> automagically once event dispatching is done entirely through
> carbon events. How is that so??

Actually, it's the other way around. You should be able to install 
event loop timers even in a WNE based carbon app, and have processing 
continue that way. However, it doesn't seem to work for some reason, at 
least not with MCL. Why exactly is not clear - Alice is looking into 
it.

Carbon Events based apps will run other cooperative threads while event 
handling continues as long as you create a timer that calls 
YieldToAnyThread.

I suggest moving to Carbon Events because Apple wants and expects 
developers to do so. CFM support is more likely to be buggy, and slower 
to be fixed than Carbon Events support, especially when trying to do 
things which weren't the norm under Classic Mac OS anyway. CFM support 
will always lag, because Apple are trying to nudge developers along the 
following path:

Classic -> Carbon CFM/PEF with resource forks -> Carbon Events Mach-O 
with flat files and .nibs in app bundles -> Cocoa

This should not, in theory, be a technical issue at all. But in 
practice, it is, because Apple support for technologies that they want 
to wean developers of is always lacking relative to those technologies
(Continue reading)

Permalink | Reply | 15 comments |

Gmane