July 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] about hex

by Henrik Johansen

Iirc, it was reintroduced in Pharo in relation to SqueakDBX, might want to check with Mariano that changes will be compatible/SqueakDBX is updated. Cheers, Henry Den 19. juli 2010 kl. 23:05 skrev StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > **Tx** > http://code.google.com/p/pharo/issues/detail?id=2699 > > Stef > > > On Jul 19, 2010, at 10:07 PM, Levente Uzonyi wrote: > >> On Mon, 19 Jul 2010, StÃ©phane Ducasse wrote: >> >>> Levente >>> Now what hex should returns? >> >> If you mean Integer >> #hex then see here: >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/151957.html >> >> >> Levente >> >>> >>> On Jul 19, 2010, at 9:33 PM, stephane ducasse wrote: >>> >>>> If I recall hex was removed because it was used for html related thing. >>>> >>>> Stef >>>> >>>> >>>> >>>> Looks like the hex method will be changed in Squeak and >>>> we should keep track using this issue to see if Pharo has >>>> to follow to keep compatible (also for Cog). >>>> >>>> See >>>> >>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/151949.html >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 20, 2010

Re: [Pharo-project] help to update actions done in Pharo 1.1

by Levente Uzonyi

On Mon, 19 Jul 2010, StÃ©phane Ducasse wrote: > > On Jul 19, 2010, at 10:08 PM, Levente Uzonyi wrote: > >> On Mon, 19 Jul 2010, StÃ©phane Ducasse wrote: >> >>> Where is the code that we should check to be included in 1.2? >> >> Basically in Squeak, but I'm sure most of them are in the Pharo bugtracker. > Thanks but > well... > tell me that this is too boring to report it which I can understand but not that > kind of answer because this is certainly not the case since I'm nearly the only one > to look at squeak fixes. The code of HashedCollection and subclasses in Pharo and Squeak are too different now, there are no patches/changesets that can convert one to the other. So a brave soul has to do it by hand. Levente > > Stef > >> >> >> Levente >> >>> >>> Stef >>> >>> On Jul 19, 2010, at 6:18 PM, Levente Uzonyi wrote: >>> >>>> On Mon, 19 Jul 2010, Henrik Johansen wrote: >>>> >>>> ... >>>> The wkd in Pharo 1.1 didn't really result in a speedup :) >>>> Better Identity hashing, encoding conversions, the other collection changes which made it in, plus rendering speedups f.ex through inlining alot of common morph extensions, and using Strike fonts by default, were though! >>>> >>>> >>>> That's a nice euphemism. I didn't check the code thoroughly, but rehashing seems to be O(n^2) in WeakKeyDictionary. This affects it's subclasses and WeakRegistry which affects the whole finalization process. >>>> >>>> (Recently I did a benchmark of Seaside 3.0, where Squeak handled 1.28x more requests/second than Pharo under "heavy load" (50 concurrent users flooding the server) with the Kom adaptor.) >>>> >>>> >>>> Levente >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 20, 2010

Re: [Pharo-project] connection to access databases

by Eliot Miranda

Hi Doru, On Mon, Jul 19, 2010 at 1:51 PM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Thanks Eliot. > > Indeed this allowed me to connect, but now I have problems executing even > simple queries. For example, when executing the following code, the > sqlAllocStmtConnection:statement: fails saying "Could not coerce > arguments": > > connection := ODBCConnection dsn: 'Test' user: '' password: ''. > connection query: 'select * from TABLE' > > Am I doing something wrong, or is it something else? > difficult to know. I was using ODBC & mysql to test the threaded VM late last year but I haven't ported this to Snow Leopard. Anyway, I used Apple's ODBC tools and the mysql tools to check the database was setup correctly before I used the ODBCConnect code. Apple's recently released their ODBC tools for SNow Leopard http://reviews.cnet.com/8301-13727_7-10330516-263.html. So I recommend using the relevant tools to check the DB is configured correctly before you try and debug ODBCConnect. cheers, Eliot > Cheers, > Doru > > > On 19 Jul 2010, at 19:39, Eliot Miranda wrote: > > moduleName >> "Return the name of the module for this library" >> Smalltalk platformName = 'Win32' ifTrue:[^'odbc32']. >> Smalltalk platformName = 'unix' ifTrue:[^ 'libodbc.so']. >> Smalltalk platformName = 'Mac OS' ifTrue:[^ 'libiodbc.dylib']. >> ^self error: 'Don''t know the ODBC library name' >> >> works for me. Find attached. >> >> On Mon, Jul 19, 2010 at 1:41 AM, Tudor Girba <tudor.girba(a)gmail.com> >> wrote: >> Hi, >> >> Thanks for all the pointers. I am now testing on Mac using the Actual >> driver: >> http://www.actualtech.com/product_access.php >> >> I managed to get it running, but now I have problems with the ODBC Pharo >> implementation because there seems to be no module for Mac: >> >> ODBCLibrary class>>moduleName >> "Return the name of the module for this library" >> SmalltalkImage current platformName = 'Win32' ifTrue: [ ^ 'odbc32' >> ]. >> SmalltalkImage current platformName = 'unix' ifTrue: [ ^ >> 'libodbc.so' ]. >> ^ self error: 'Don''t know the ODBC library name' >> >> Is there something to be done in this area? >> >> Cheers, >> Doru >> >> >> On 19 Jul 2010, at 01:04, GermÃ¡n Arduino wrote: >> >> Yes, Indeed, I mean, I used a driver to access, but can't remember now >> the brand, but I'm sure I not payed for it :) >> >> May be I used some trial version.... >> >> 2010/7/18 Levente Uzonyi <leves(a)elte.hu>: >> >> On Sun, 18 Jul 2010, GermÃ¡n Arduino wrote: >> >> Not, I'm not talking of propietary software. >> >> I'm talking of one I used when helped Diego with the testing of the >> odbc package. Don't remember now, but may be this >> http://www.unixodbc.org/ ? >> >> ODBC is just an API, if you don't have a driver for yourdatabase, then it >> won't help. >> >> >> Levente >> >> >> About Mac, sorry, never touched a mac in all my life.... >> >> Cheers. >> >> >> 2010/7/18 Levente Uzonyi <leves(a)elte.hu>: >> >> On Sun, 18 Jul 2010, GermÃ¡n Arduino wrote: >> >> Hi Tudor: >> >> Is as Levente says, you must define an ODBC source on a Windows PC >> (Alternatively on Unix you can use ODBC also). >> >> I don't know any free ODBC drivers for Access on un*x. I only know a >> driver >> which costs 4-5 times more than the windows OS itself :). But >> there's a driver for mac which costs only 30 usd if you're interested. >> >> >> Levente >> >> >> Some examples on: http://wiki.squeak.org/squeak/2480 >> >> Cheers. >> GermÃ¡n. >> >> >> 2010/7/18 Levente Uzonyi <leves(a)elte.hu>: >> >> On Sun, 18 Jul 2010, Tudor Girba wrote: >> >> Thanks Mariano! >> >> Indeed, if I load ConfigurationOfFFI first, everything loads well. >> >> I am a complete newbie in this area. Can anyone tell me what I should >> do >> next? >> >> I imagine that I should connect to an Access server. If yes, how would >> I >> do that? >> >> Also, do I need anything else, like a C plugin/library to get the C >> calls >> from ODBCLibrary going? >> >> First you'll need a pc running windows. Then you have to create an ODBC >> Data >> Source for your Access file. Then you'll be able to create a connection >> to >> that datasource from your image. >> >> >> Levente >> >> >> Cheers, >> Doru >> >> >> On 18 Jul 2010, at 09:17, Mariano Martinez Peck wrote: >> >> >> >> On Sun, Jul 18, 2010 at 8:49 AM, Tudor Girba <tudor.girba(a)gmail.com> >> wrote: >> Hi, >> >> I tried loading it, but I get : >> "This package depends on the following classes: >> ExternalLibrary >> ExternalStructure" >> >> Can anyone tell me where to find these from? >> >> This means that you need Metacello ;) >> >> Those classes are from FFI, a pre-requisite for ODBC to work. >> Maybe there is a ConfigurationOfODBC somewhere... >> >> For the moment, I recommend you to install FFI using the >> ConfigurationOfFFI. >> >> Cheers >> >> Mariano >> >> >> Also, are there eternal prerequisites to work with ODBC? >> >> Cheers, >> Doru >> >> >> >> On 18 Jul 2010, at 00:35, Levente Uzonyi wrote: >> >> On Sat, 17 Jul 2010, Tudor Girba wrote: >> >> Hi, >> >> Is there a way to connect to a Microsoft Access database from Pharo? >> >> Yes, with ODBC. >> >> >> Levente >> >> >> I have an mdb file of 300 Mb that I would need to analyze. >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "Next time you see your life passing by, say 'hi' and get to know >> her." >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> www.tudorgirba.com >> >> "Speaking louder won't make the point worthier." >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> www.tudorgirba.com >> >> "When people care, great things can happen." >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> >> -- >> ================================================= >> GermÃ¡n S. Arduino <gsa @ arsol.net> Twitter: garduino >> Arduino Software & Web Hosting http://www.arduinosoftware.com >> PasswordsPro http://www.passwordspro.com >> ================================================= >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> www.tudorgirba.com >> >> "Every thing should have the right to be different." >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> <ODBCLibrary >> class-moduleName.st>_______________________________________________ >> >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > www.tudorgirba.com > > "Every thing has its own flow." > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 19, 2010

Re: [Pharo-project] Monticello mcz files write their DataStream and a portion of their chunk-files as WideStrings, which are non-portable.

by StÃ©phane Ducasse

thanks for the info. So some people will have to investigate because my plate is more than full. Stef On Jul 19, 2010, at 11:43 PM, Paul DeBruicker wrote: > > >> Interesting. >> Now is the problem happening with other packages than a JS related? >> >> Stef >> >> > >> Hi- >> > > Hi - > > Yes. If you attempt to load the latest Money package I uploaded to SqueakSource into Gemstone it fails because it requires the Currency class, which is provide by the Money package. The Money package doesn't use any JS. The Money package loads just fine into Pharo. It behaves in the same way as the JQWidgetBox-FullCalendar-Core package. > > > Thanks > > Paul > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 19, 2010

Re: [Pharo-project] A facility to launch external processes from Pharo should be provided by default on all platforms

by StÃ©phane Ducasse

On Jul 19, 2010, at 11:38 PM, Levente Uzonyi wrote: > On Mon, 19 Jul 2010, Eliot Miranda wrote: > >> Hi Levente, >> >> at Cadence I extended the plugin so we could connect to Subversion via >> the plugin because Newspeak at one point used a Subversion backend to >> Monticello for source-code control. If you're interested I have the plugin >> and can dig up the image-side code. > > Does that mean that OSProcess can be used on all platforms? If yes, then it would be great. that would be gorgeous. > > > Levente > >> >> On Mon, Jul 19, 2010 at 1:05 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >> >>> On Mon, 19 Jul 2010, Gabriel Cuvillier wrote: >>> >>> >>>> Hello everyone, >>>> >>>> I've read several threads about people having problems to launch external >>>> processes from Pharo. >>>> >>>> The solutions are well known: either by using ProcessWrapper, or by using >>>> the plugin OSProcess. But the former is Win32 only, and the latter is >>>> supposedly cross platform, but is only included by default on Linux and OS >>>> X... On Win32, the plugin must be built by hand with the Squeak VM. >>>> >>> >>> AFAIK the Win32OSProcessPlugin is included with the SqueakVM for windows. >>> The only reason I wrote ProcessWrapper is that OSProcess doesn't support >>> pipes on windows, so you can't use stdin, stdout or stderr. >>> >>> >>>> For the average user, this is a little bit puzzling. Unless things >>>> operates in a closed sandbox (no files, no sockets, ...), such basic >>>> operation should be included by default and usable in a cross platform way >>>> (even if we are living in an image, no?). >>>> >>>> For example, here is my use case: I have several command line tools to >>>> automate tasks on my machine. I intended to learn Pharo/Smalltalk by >>>> building a graphical front-end to these tools (with Morphic) as well as a >>>> Web front-end (with Seaside). But the "system()" message is missing :) >>>> >>>> Gabriel. >>>> >>>> Note: Maybe it is more a SqueakVM issue. If so, I will post my request on >>>> that mailing list. >>>> >>> >>> Pharo uses the SqueakVM. >>> >>> >>> Levente >>> >>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 19, 2010

Re: [Pharo-project] Monticello mcz files write their DataStream and a portion of their chunk-files as WideStrings, which are non-portable.

by Paul DeBruicker

> Interesting. > Now is the problem happening with other packages than a JS related? > > Stef > > >/ Hi- > / Hi - Yes. If you attempt to load the latest Money package I uploaded to SqueakSource into Gemstone it fails because it requires the Currency class, which is provide by the Money package. The Money package doesn't use any JS. The Money package loads just fine into Pharo. It behaves in the same way as the JQWidgetBox-FullCalendar-Core package. Thanks Paul

July 19, 2010

Re: [Pharo-project] [Vm-dev] RE: Fwd: [squeak-dev] Re: Debug-it and external calls

by Eliot Miranda

On Mon, Jul 19, 2010 at 1:10 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > > If the FFI call is flawed, why does it work when not stepping in the > debugger? I'm not buying it :) > A few people have seen problems with the part of the debugger in question. Here's the canonical version of the method by Andreas 'ar 5/25/2000 20:41'. It is invoked from ContextPart>>doPrimitive:method:receiver:args: and its job is to invoke just the primitive and either answer the result or a special PrimitiveFailed token. The debugger then checks for the result being the PrimitiveFailed token and if so steps into the method. ContextPart>>tryNamedPrimitiveIn: aCompiledMethod for: aReceiver withArgs: arguments "Hack. Attempt to execute the named primitive from the given compiled method" | selector theMethod spec | arguments size > 8 ifTrue:[^PrimitiveFailToken]. selector _ #( tryNamedPrimitive tryNamedPrimitive: tryNamedPrimitive:with: tryNamedPrimitive:with:with: tryNamedPrimitive:with:with:with: tryNamedPrimitive:with:with:with:with: tryNamedPrimitive:with:with:with:with:with: tryNamedPrimitive:with:with:with:with:with:with: tryNamedPrimitive:with:with:with:with:with:with:with:) at: arguments size+1. theMethod _ aReceiver class lookupSelector: selector. theMethod == nil ifTrue:[^PrimitiveFailToken]. spec _ theMethod literalAt: 1. spec replaceFrom: 1 to: spec size with: (aCompiledMethod literalAt: 1) startingAt: 1. ^aReceiver perform: selector withArguments: arguments What this does is slam the named primitive to be evaluated into the relevant implementation of tryNamedPrimitive[:with:with:with:with:with:with:with:] and invoke it. One minor problem is that there are only 9 methods so there's only support for 0 to 8 arguments. The real problem with this is that it doesn't flush the VM's method lookup cache and so one can end up invoking a different named primitive, one that was installed into the same method by a previous invocation of tryNamedPrimitiveIn:for:withArgs:. Michael Haupt saw the effect of this doing bytecode simulation on Cog. For some reason it's much more likely to hit the cache flush issue in Cog tan in the standard interpreter (probably because Cog makes less use of the method cache because machine code sends have their send caches inline in the machine code). I fixed this for Michael by using the following version 'eem 5/23/2010 14:13' ContextPart>>tryNamedPrimitiveIn: aCompiledMethod for: aReceiver withArgs: arguments "Hack. Attempt to execute the named primitive from the given compiled method" | selector theMethod spec | arguments size > 8 ifTrue:[^PrimitiveFailToken]. selector := #( tryNamedPrimitive tryNamedPrimitive: tryNamedPrimitive:with: tryNamedPrimitive:with:with: tryNamedPrimitive:with:with:with: tryNamedPrimitive:with:with:with:with: tryNamedPrimitive:with:with:with:with:with: tryNamedPrimitive:with:with:with:with:with:with: tryNamedPrimitive:with:with:with:with:with:with:with:) at: arguments size+1. theMethod := aReceiver class lookupSelector: selector. theMethod == nil ifTrue:[^PrimitiveFailToken]. spec := theMethod literalAt: 1. spec replaceFrom: 1 to: spec size with: (aCompiledMethod literalAt: 1) startingAt: 1. theMethod flushCache. selector flushCache. ^aReceiver perform: selector withArguments: arguments It adds "theMethod flushCache. selector flushCache" to flush the cache and at least for a couple of months things seemed to be OK. But Michael sent me a different case a week ago that turns out to be due to exactly the same cause. When simulated his code was trying to invoke the primDigitDivNegative primitive via digitDiv:neg: (which doesn't exist in Cog and so should simply fail) but it was succeeding, running some bogus primitive. There is a more fundamental issue with the above. try debugging it. If you do you stand a good chance of the debugger overwriting what the debugger version of the method is trying to effect. That's why if you look at the analogous machinery for num bered primitives you'll see the above approach (which was used in Smalltalk-80 V2) is discarded and a much more reliable approach, a primitive-executing primitive, is used, namely ProtoObject>>#tryPrimitive:withArgs: 'ajh 1/31/2003 22:21': ProtoObject>>tryPrimitive: primIndex withArgs: argumentArray "This method is a template that the Smalltalk simulator uses to execute primitives. See Object documentation whatIsAPrimitive." <primitive: 118> ^ ContextPart primitiveFailToken In the Teleplace images I've taken a similar approach, providing a primitive in Cog. The below is slightly different because the Teleplace images debugger supports primitive error codes (and I need to fold this back into Squeak asap). ContextPart>>tryNamedPrimitiveIn:for:withArgs: eem 5/12/2009 ContextPart>>tryNamedPrimitiveIn: aCompiledMethod for: aReceiver withArgs: arguments | selector theMethod spec receiverClass | <primitive: 218 error: ec> ec ifNotNil: ["If ec is an integer other than -1 there was a problem with primitive 218, not with the external primitive itself. -1 indicates a generic failure (where ec should be nil) but ec = nil means primitive 218 is not implemented. So interpret -1 to mean the external primitive failed with a nil error code." ec isInteger ifTrue: [ec = -1 ifTrue: [ec := nil] ifFalse: [self primitiveFailed]]. ^{PrimitiveFailToken. ec}]. "Assume a nil error code implies the primitive is not implemented and fall back on the old code." "Hack. Attempt to execute the named primitive from the given compiled method" arguments size > 8 ifTrue: [^{PrimitiveFailToken. nil}]. selector := #( tryNamedPrimitive tryNamedPrimitive: tryNamedPrimitive:with: tryNamedPrimitive:with:with: tryNamedPrimitive:with:with:with: tryNamedPrimitive:with:with:with:with: tryNamedPrimitive:with:with:with:with:with: tryNamedPrimitive:with:with:with:with:with:with: tryNamedPrimitive:with:with:with:with:with:with:with:) at: arguments size+1. receiverClass := self objectClass: aReceiver. theMethod := receiverClass lookupSelector: selector. theMethod == nil ifTrue: [^{PrimitiveFailToken. nil}]. spec := theMethod literalAt: 1. spec replaceFrom: 1 to: spec size with: (aCompiledMethod literalAt: 1) startingAt: 1. Smalltalk unbindExternalPrimitives. ^self object: aReceiver perform: selector withArguments: arguments inClass: receiverClass With this approach there's no argument count limit and there's no chance of executing the wrong primitive. But it requires a primitive in the VM. Perhaps the VM folks can take a look at porting the Cog primitive primitiveDoNamedPrimitiveWithArgs back to the base VM and then we can use something like the above with the fallback code, liberally sprinkled with cache flushes, only as a fallback. HTH Eliot > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko > Sent: Monday, July 19, 2010 3:02 PM > To: Pharo Development > Subject: [Pharo-project] Fwd: [squeak-dev] Re: Debug-it and external calls > > ---------- Forwarded message ---------- > From: Igor Stasenko <siguctua(a)gmail.com> > Date: 19 July 2010 23:00 > Subject: Re: [squeak-dev] Re: [Pharo-project] Debug-it and external calls > To: The general-purpose Squeak developers list < > squeak-dev(a)lists.squeakfoundation.org> > > > On 19 July 2010 21:42, Andreas Raab <andreas.raab(a)gmx.de> wrote: > > On 7/19/2010 9:29 AM, Igor Stasenko wrote: > >> > >> No, debugger, actually doing a primitive call, but in order to > >> intercept a primitive failure and 'step into' method, it does the > >> trick with replacing the subject method with temporary method (which > >> will call the same primitive with same arguments& recevier). > >> Then, if primitive runs ok, it simply behaves as a 'step over', and > >> if primitive fails, then debugger itercepts it and creates a context > >> for subject method, which should handle primitive failure. > > > > Correct. Stepping over FFI calls will only fail if the FFI call > > actually fails. So whatever the problem it's somewhere in your FFI call. > > > But! The problem which i discovered not long ago, that if FFI method > contains many arguments (close to max 15), then debugger is unable to invoke > it, because #perform:... method works in a way, that its using temps of > context, where it were invoked. I fixed it by setting a #perform method's > frame to be a large one. > > > See http://bugs.squeak.org/view.php?id=7534 > > > Cheers, > > - Andreas > > > >> On 19 July 2010 19:22, Schwab,Wilhelm K<bschwab(a)anest.ufl.edu> wrote: > >>> > >>> So the external call does not happen and the fall-back code executes. > >>> That explains it. It might be nice if FFI calls could be made to > >>> happen, or at least to have a more informative error message, such > >>> as "Primitive not executed by the debugger" rather than "Unable to find > function address." > >>> > >>> Bill > >>> > >>> > >>> > >>> > >>> ________________________________________ > >>> From: pharo-project-bounces(a)lists.gforge.inria.fr > >>> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente > >>> Uzonyi [leves(a)elte.hu] > >>> Sent: Monday, July 19, 2010 12:20 PM > >>> To: Pharo-project(a)lists.gforge.inria.fr > >>> Subject: Re: [Pharo-project] Debug-it and external calls > >>> > >>> On Mon, 19 Jul 2010, Schwab,Wilhelm K wrote: > >>> > >>>> I often (not always??) find that using the Debug-it command and > >>>> debugging into an external call (FFI) leads to a false claim of > >>>> "Unable to find function address." Stepping over the call works; > >>>> stepping into it make it look like it fails. > >>>> > >>>> I am curently using a 1.1 RC2 image and the 4.0.3 vm on Ubuntu. I > >>>> cannot easily move the offending code to Windows, nor do I > >>>> particularly care to do so (feels good<g>), and FFI is fairly uncommon > in Squeak/Pharo. > >>>> > >>>> Can anyone else tinker with this to see if it is real? > >>> > >>> IIRC when you're using the debugger, primitives are not evaluated. > >>> > >>> > >>> Levente > >>> > >>>> > >>>> Bill > >>>> > >>>> > >>>> _______________________________________________ > >>>> Pharo-project mailing list > >>>> Pharo-project(a)lists.gforge.inria.fr > >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>>> > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> > >>> > >> > >> > >> > > > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 19, 2010

Re: [Pharo-project] A facility to launch external processes from Pharo should be provided by default on all platforms

by Levente Uzonyi

On Mon, 19 Jul 2010, Eliot Miranda wrote: > Hi Levente, > > at Cadence I extended the plugin so we could connect to Subversion via > the plugin because Newspeak at one point used a Subversion backend to > Monticello for source-code control. If you're interested I have the plugin > and can dig up the image-side code. Does that mean that OSProcess can be used on all platforms? If yes, then it would be great. Levente > > On Mon, Jul 19, 2010 at 1:05 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > >> On Mon, 19 Jul 2010, Gabriel Cuvillier wrote: >> >> >>> Hello everyone, >>> >>> I've read several threads about people having problems to launch external >>> processes from Pharo. >>> >>> The solutions are well known: either by using ProcessWrapper, or by using >>> the plugin OSProcess. But the former is Win32 only, and the latter is >>> supposedly cross platform, but is only included by default on Linux and OS >>> X... On Win32, the plugin must be built by hand with the Squeak VM. >>> >> >> AFAIK the Win32OSProcessPlugin is included with the SqueakVM for windows. >> The only reason I wrote ProcessWrapper is that OSProcess doesn't support >> pipes on windows, so you can't use stdin, stdout or stderr. >> >> >>> For the average user, this is a little bit puzzling. Unless things >>> operates in a closed sandbox (no files, no sockets, ...), such basic >>> operation should be included by default and usable in a cross platform way >>> (even if we are living in an image, no?). >>> >>> For example, here is my use case: I have several command line tools to >>> automate tasks on my machine. I intended to learn Pharo/Smalltalk by >>> building a graphical front-end to these tools (with Morphic) as well as a >>> Web front-end (with Seaside). But the "system()" message is missing :) >>> >>> Gabriel. >>> >>> Note: Maybe it is more a SqueakVM issue. If so, I will post my request on >>> that mailing list. >>> >> >> Pharo uses the SqueakVM. >> >> >> Levente >> >> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

July 19, 2010

Re: [Pharo-project] Monticello mcz files write their DataStream and a portion of their chunk-files as WideStrings, which are non-portable.

by Dale Henrichs

I've added a little more information to Issue 2697 and I'm willing to help on the GemStone-side. It looks like a WideString has snuck into the mcz file ... seems to be similar to the WideStrings showing up in the changes file issue (Issue 830 ... which appears to resurface periodicaly:)), but I haven't looked closely at how it could happen, although if the changes file had a WideString in it then the WideString could easily migrate into the mcz file... Dale Paul DeBruicker wrote: > Hi- > I created an issue in the tracker: > https://code.google.com/p/pharo/issues/detail?id=2697 > > Some packages that were created with and load fine into Pharo 1.1 release do not load into Gemstone because of the use of WideStrings while creating the mcz files. I don't know how to dissect the mcz files at this time but in describing my issue on the GLASS list, Dale Henrichs was able to reproduce the problem and diagnose it. His diagnosis is pasted below. > > To recreate my issue you must be using Gemstone 2.4.4.1, Glass 1.0-beta8.2, and GemTools for Gemstone 2.4.4. First load the ConfigurationOfJQueryWidgetBox package from the Metacello Repository on SqueakSource. Then run: > > (ConfigurationOfJQueryWidgetBox project latestVersion) > load: #('JQWidgetBox-FullCalendar-Core'). > > It will attempt to load the package but complain that a dependency for the JQFullCalendar Class is not met. The JQFullCalendar class is provided by the JQWidgetBox-FullCalendar-Core package. > > Our entire discussion leading up to his diagnosis is here: http://forum.world.st/aFilePackage-cannot-perform-the-selector-preamble-wit… > > > > Is there a way to write the mcz files using something other than WideStrings that will allow me to attempt to load them into Gemstone and perhaps get a different result? > > Thanks > > Paul > > > Paul, > > Okay, it looks to me like your mcz file(s) are "corrupted" ... probably > due to a bug in Pharo 1.2 (that's the version you're using right?). > > In an mcz file the snapshot of the definitions are serialized using two > formats: > > 1. a DataStream on an ordered collection of MCDefintions > 2. a chunk-file formatted string. > > It appears that for the DataStream, the entire(?) stream is written as a > WideString ... WideString is Squeak/Pharo dependent and is not portable > at all ... this is new. When GemStone hits the widestring an error is > thrown and Monticello tries to use the chunk-file format (which is why > you ran into the preamble probelm ... chunk file format is normally hit > (nor is it desirable to hit it)... > > The chunk file-file is partially written as a WideString again...because > the WideString is not portable it breaks the parsing algorithms for > GemStone ... interestingly enough the chunk-file string looks to be a > WideString for the first hundred characters or so ... > > One of three things is happening: > > 1. someone in Pharo land decided it was a "good idea" to create mcz > files using WideString > 2. The that you used to create the class had a WideString in it > 3. there is a bug somewhere in the pharo/monticello implementation > > I can't guess which of those 3 the problem is and I can't guess what the > solution might be either. > > If you bring up this bug on the Pharo list, I'll monitor the list and if > I can step in and help, I will. > > Dale > > >

July 19, 2010

Re: [Pharo-project] pharo website - screencasts

by Mariano Martinez Peck

maybe it is good to ask pharo users also. I cc'ed them. this is cool laurent :) mariano On Mon, Jul 19, 2010 at 9:10 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > good initiative > > May be you should say > more screencasts at: ... > > On Jul 19, 2010, at 8:55 PM, laurent laffont wrote: > > > Hi, > > > > I've added a "screencast wall" at > http://pharo-project.org/documentation/screencasts > > > > I've tried to put those which best show Pharo for newcommers, feedback > welcome. > > > > Cheers, > > > > Laurent Laffont > > > > http://pharocasts.blogspot.com/ > > http://magaloma.blogspot.com/ > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 19, 2010