[ANN] TDDFacilities

Anyone here using FFI (and possibly ODBC) with Pharo?

Trying the SUnit tests that comes with the package makes the VM crash.  BAM!  Quick & simple exit as soon as I run it!

 

-----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
Blog: lamneth.wordpress.com
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein)

---

Looking for the perfect gift? Give the gift of Flickr!

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Mariano Martinez Peck wrote:

2009/6/26 Benoit St-Jean <[hidden email] <mailto:[hidden email]>>

   Anyone here using FFI (and possibly ODBC) with Pharo?


Yes I am, in SqueakDBX. For latests Pharo images (closure images) you need FFI-Kernel-ar.9 (the latest FFI version). You can simply evaluate: ScriptLoader loadFFI.

Which OS are you using? I test it here in Windows and have the same results, the image crash. In Linux I think I don't have this problem.

Andres, do you know what can be the problem?

Sorry, what was the question?

Cheers,
 - Andreas

Anyway, FFI is working well (without taking in mind FFI tests). I have SqueakDBX perfectly working (and it uses FFI).

For ODBC: I can told you 2 things:

1) Search in this list because there was a topic about this in this week (http://n2.nabble.com/ODBC-on-Pharo--td3152288.html#a3152288) and there should be more.

2) You can try SqueakDBX instead of ODBC. It has not only an ODBC backend, but also Oracle, MySQL, PostgreSQL, Sqlite3 and MS SQLServer. It also works in Linux, Mac and Windows (depends on the database). And finally, when possible, we use asynchronous queries so that to lock the VM as little as possible. For further information, read our wiki: http://wiki.squeak.org/squeak/6052

Best,

Mariano

 

   Trying the SUnit tests that comes with the package makes the VM
   crash.  BAM!  Quick & simple exit as soon as I run it!
       -----------------
   Benoit St-Jean
   Yahoo! Messenger: bstjean

   Blog: lamneth.wordpress.com <http://lamneth.wordpress.com>

   A standpoint is an intellectual horizon of radius zero.
   (Albert Einstein)

   ------------------------------------------------------------------------

   Looking for the perfect gift?* Give the gift of Flickr!*
   <http://www.flickr.com/gift/>

   _______________________________________________
   Pharo-project mailing list
   [hidden email]

   <mailto:[hidden email]>

   http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Mariano Martinez Peck wrote:

Download latest Windows VM  (Squeak 3.11.2) from Pharo webpage. Then evaluate ScriptLoader loadFFI and try to run FFI tests. The image will crash!

Interesting. This appears to be a Pharo-only problem. I ran the FFI tests using the 3.11.2 VM on the current 3.10.2 release image and they works fine. I've also ran the test against a 3.10.2 closure converted image (on the off-chance that it might be closure related) and the tests pass too. So I don't really think it's an FFI problem. You'll probably have to ask Pharo people to help you with the problem; the FFI appears to be fully functional on both pre- and post-closure images.

Cheers,
 - Andreas

Mariano Martinez Peck wrote:

Ok. Pharo people is in this mail. Let's wait if someone can help us.

Please cc vm-dev on any responses. I'm not subscribed to the Pharo list.

I don't know why in mi Windows machine the dump file is not generated :(

It looks like the crash has two different ways of showing. In the first situation, it crashes with a recursive DNU. In the second, it actually does generate a crash dump (attached). The latter seems to happen when you try to step through the code.

Benoit St-Jean can you attach the complete dump file?

I tried this in Linux and it doesn't crash my image. So, only windows :(

Difficult to say. There is a good possibility that the problem is unrelated to the FFI since I have been completely unable to reproduce the problem elsewhere.

Cheers,
 - Andreas

I crated the issue so that no to forget about it:

http://code.google.com/p/pharo/issues/detail?id=908

Best,

Mariano

On Sun, Jun 28, 2009 at 3:56 AM, Andreas Raab <[hidden email]> wrote:

Mariano Martinez Peck wrote:

Ok. Pharo people is in this mail. Let's wait if someone can help us.

Please cc vm-dev on any responses. I'm not subscribed to the Pharo list.

I don't know why in mi Windows machine the dump file is not generated :(

It looks like the crash has two different ways of showing. In the first situation, it crashes with a recursive DNU. In the second, it actually does generate a crash dump (attached). The latter seems to happen when you try to step through the code.

Benoit St-Jean can you attach the complete dump file?

I tried this in Linux and it doesn't crash my image. So, only windows :(

Difficult to say. There is a good possibility that the problem is unrelated to the FFI since I have been completely unable to reproduce the problem elsewhere.

Cheers,
 - Andreas

Mariano

I just published in Pharo a new ScriptLoader which I hope fix the
problem.
Could you check it?

Stef

On Jul 5, 2009, at 9:05 PM, Mariano Martinez Peck wrote:

> Andreas: can you see new comments here: http://code.google.com/p/pharo/issues/detail?id=908
>
> What do you think?
>
> Thanks!
>
> Mariano
>
> On Tue, Jun 30, 2009 at 12:26 PM, Mariano Martinez Peck <[hidden email]
> > wrote:
> I crated the issue so that no to forget about it:
>
> http://code.google.com/p/pharo/issues/detail?id=908
>
> Best,
>
> Mariano
>
>
> On Sun, Jun 28, 2009 at 3:56 AM, Andreas Raab <[hidden email]>
> wrote:
> Mariano Martinez Peck wrote:
> Ok. Pharo people is in this mail. Let's wait if someone can help us.
>
> Please cc vm-dev on any responses. I'm not subscribed to the Pharo
> list.
>
>
> I don't know why in mi Windows machine the dump file is not
> generated :(
>
> It looks like the crash has two different ways of showing. In the
> first situation, it crashes with a recursive DNU. In the second, it
> actually does generate a crash dump (attached). The latter seems to
> happen when you try to step through the code.
>
>
> Benoit St-Jean can you attach the complete dump file?
>
> I tried this in Linux and it doesn't crash my image. So, only
> windows :(
>
> Difficult to say. There is a good possibility that the problem is
> unrelated to the FFI since I have been completely unable to
> reproduce the problem elsewhere.
>
> Cheers,
>  - Andreas
>
>

> _______________________________________________
> Pharo-project mailing list
> [hidden email]

> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]

http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Jul 7, 2009, at 11:20 PM, Mariano Martinez Peck wrote:

> Stef: Yes, it works. But, I have some questions:
>
> 1) Is it ok to have
>
> self new installer monticello http:
> 'source.squeakfoundation.org';     ???
>
> or it is just temp ? In addition, why was #squeakfundation removed ?
> this is because now all is here: source.squeakfoundation.org???   If
> so, we can create a method for this new repository...

It is temporary.
First I would say that FFI should have a loader doing the
initialization properly. 

Second we will probably have a new loader in the near future.

> 2) I don't know what Smalltalk recreateSpecialObjectsArray.

specialObjectsArray is an array known by the VM

> But older version of FFI worked ok and also this version works ok in
> Linux...I don't understand why.

I do not know :)

> Is there a logic here I cannot see ?
> Is there a drawback in evaluating Smalltalk
> recreateSpecialObjectsArray. ?
>
> Cheers,
>
> Mariano
>
> On Tue, Jul 7, 2009 at 8:01 PM, Stéphane Ducasse <[hidden email]
> > wrote:
> Mariano
>
> I just published in Pharo a new ScriptLoader which I hope fix the
> problem.
> Could you check it?
>
> Stef
>
> On Jul 5, 2009, at 9:05 PM, Mariano Martinez Peck wrote:
>
> > Andreas: can you see new comments here: http://code.google.com/p/pharo/issues/detail?id=908
> >
> > What do you think?
> >
> > Thanks!
> >
> > Mariano
> >
> > On Tue, Jun 30, 2009 at 12:26 PM, Mariano Martinez Peck <[hidden email]
> > > wrote:
> > I crated the issue so that no to forget about it:
> >
> > http://code.google.com/p/pharo/issues/detail?id=908
> >
> > Best,
> >
> > Mariano
> >
> >
> > On Sun, Jun 28, 2009 at 3:56 AM, Andreas Raab <[hidden email]>
> > wrote:
> > Mariano Martinez Peck wrote:
> > Ok. Pharo people is in this mail. Let's wait if someone can help us.
> >
> > Please cc vm-dev on any responses. I'm not subscribed to the Pharo
> > list.
> >
> >
> > I don't know why in mi Windows machine the dump file is not
> > generated :(
> >
> > It looks like the crash has two different ways of showing. In the
> > first situation, it crashes with a recursive DNU. In the second, it
> > actually does generate a crash dump (attached). The latter seems to
> > happen when you try to step through the code.
> >
> >
> > Benoit St-Jean can you attach the complete dump file?
> >
> > I tried this in Linux and it doesn't crash my image. So, only
> > windows :(
> >
> > Difficult to say. There is a good possibility that the problem is
> > unrelated to the FFI since I have been completely unable to
> > reproduce the problem elsewhere.
> >
> > Cheers,
> >  - Andreas
> >
> >
> > _______________________________________________
> > Pharo-project mailing list
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Having made some bozo statements lately, I am hesitant to even inquire
(because I am probably doing something dumb), but...

I noted an error in my code that read xxx isNumber ifNil: [...] and
figured that when I imported in from VisualWorks, I must have "fixed"
things too hastily. Wondering where else I may have made this error I
did the following on an iMac using the 10371web image recently posted:

In a workspace I typed and highlighted "ifNil:" --without the quotes
of course-- and selected "extended search...".
Then I selected "senders of it (n)", and to my surprise, not my
erroneous method was not displayed in the results. Ten (10) methods
turn up in the results, and some of them are not actually senders of
it; the non-senders may include the pattern in an array, or as a
substring of some symbol.

Is this a known defect? Previously (from images two months ago and
less) this searching worked as expected.

A search of the defect db, using only the word "senders", gave me this
(semi-related) issue:
http://code.google.com/p/pharo/issues/detail?id=261&q=sendeifNilrs&colspec=ID%20Type%20Status%20Summary%20Milestone

Thanks in advance,
Cam

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Mariano Martinez Peck wrote:

Andreas: can you see new comments here: http://code.google.com/p/pharo/issues/detail?id=908

What do you think?

Close, but not quite right ;-) The problem with your theory is that Smalltalk recreateSpecialObjectsArray is specifically called from a postscript in FFI-Kernel so there shouldn't be a problem with it.

Unless of course there is something wrong with Monticello in Pharo ... let me see. Yup. Looks like that's it. I just added a halt to recreateSpecialObjectsArray then used ScriptLoader loadFFI and it's just not being called.

It would be interesting to see if the postscript is executed when you load the FFI on your Unix machine (the one where you said it didn't crash).

In any case, looks like I was right and it isn't an FFI problem but rather a problem with Monticello. The workaround with the explicit recreateSpecialObjectsArray will work but of course any other packages that use postscripts will likely have similar issues.

Cheers,
 - Andreas

On Jul 7, 2009, at 7:39 PM, Mariano Martinez Peck wrote (below my original text):

can you give us a concrete example?

In my opinion, if you have a symbol with that text, it must be found by "senders of it". In VAST it is like that.
So, if you have #ifNil:   for me it is correct to be found.

best,

Mariano

What you say makes sense for performance reasons. I just picked through those 10 methods more carefully, and they each contain the symbol #ifNil:, so the one error I thought I was seeing (of a match for a pattern of xxxIfNil:) is not what is causing them to be found. So, I'm glad you asked, as that forced me to recheck that aspect. Should it be called "search->methods referencing symbol (n)" or something -- I don't care about pesky details like that. 

What matters to me is the failure to find my references/sends:

My broken method (FaTableAccessor>>columnAt:) is just one of *many* places I have used #ifNil:, and is NOT being found.

The search is only finding 10 methods in the entire system (in the classes Decompiler, MessageNode, MethodFinder, OCompletionTable, PSUIManager, RBMessageNode, RBProgramNode) that reference the symbol #ifNil:.

Previously, this feature has worked for me as expected (to the best of my knowledge). But I can't guarantee that I have ever searched for #ifNil:. 

I just searched for collect:, and that turned up a more reasonable 1092 methods, some of which are mine. I am surprised there are not more uses of it, but at least it is a more credible number than "10". So maybe it is just something weird for the symbol ifNil:, which I can live with; that would make this a low priority issue, assuming it is working for most other symbols pretty well.

Recap: I am selecting "ifNil:" (without the quotes) in a workspace, and using "extended search"->"senders of it (n)"; this is failing to find methods of mine that include the symbol (as a selector).

Happy Hunting,

Cam

On Tue, Jul 7, 2009 at 6:32 PM, Cameron Sanders <[hidden email]> wrote:

Having made some bozo statements lately, I am hesitant to even inquire
(because I am probably doing something dumb), but...

I noted an error in my code that read xxx isNumber ifNil: [...] and
figured that when I imported in from VisualWorks, I must have "fixed"
things too hastily. Wondering where else I may have made this error I
did the following on an iMac using the 10371web image recently posted:

In a workspace I typed and highlighted "ifNil:" --without the quotes
of course-- and selected "extended search...".
Then I selected "senders of it (n)", and to my surprise, not my
erroneous method was not displayed in the results. Ten (10) methods
turn up in the results, and some of them are not actually senders of
it; the non-senders may include the pattern in an array, or as a
substring of some symbol.

 

Is this a known defect? Previously (from images two months ago and
less) this searching worked as expected.

A search of the defect db, using only the word "senders", gave me this
(semi-related) issue:
http://code.google.com/p/pharo/issues/detail?id=261&q=sendeifNilrs&colspec=ID%20Type%20Status%20Summary%20Milestone

Thanks in advance,
Cam

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project