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

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

by Schwab,Wilhelm K

If the FFI call is flawed, why does it work when not stepping in the debugger? I'm not buying it :) -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@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] help to update actions done in Pharo 1.1

by Levente Uzonyi

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. 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 >

July 19, 2010

Re: [Pharo-project] about hex

by Levente Uzonyi

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 >

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, 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 >

July 19, 2010

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

by Igor Stasenko

---------- 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.

July 19, 2010

Re: [Pharo-project] Cleaning morphic - Step 1 - About "Morphic-Ballon" and the Ballon category

by Miguel Enrique CobÃ¡ MartÃnez

El lun, 19-07-2010 a las 15:58 -0300, Guillermo Polito escribiÃ³: > HAhah, thanks :). > > Anyway, my idea is not to remove those packages. I want to put them > in separate monticello packages, so we don't need have it in the core > if we don't use it. > > So, I download Seaside, Moose, and what else? Magma, RFB, Pier, Magritte. :) > > 2010/7/19 Mariano Martinez Peck <marianopeck(a)gmail.com> > Guille: one thing you can do before removing the code, is to > prepare an DEV image with Seaside, Moose and all those big > projects. So that when you search senders/references you can > do it also there. I don't mean that we shouldn't remove them > if they are used in those projects, but just to be aware. > > but for "coding" and commiting, yes, use latest PharoCore, not > dev. > > And yes, if you don't receive feedback, go ahead! > > Cheers > > Mariano > > 2010/7/19 Guillermo Polito <guillermopolito(a)gmail.com> > > Ok, I opened an Issue for this... > > http://code.google.com/p/pharo/issues/detail?id=2696 > > > > On Thu, Jul 15, 2010 at 8:18 PM, Guillermo Polito > <guillermopolito(a)gmail.com> wrote: > Hi! > > Does anyone know what the Ballon category and > its related morphs are for? Someone uses it? > Is it useful in the Core of pharo? > > Did Someone try previously to remove it and > failed? why? > > thanks in advance :) > Guille > > > > > _______________________________________________ > 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 -- Miguel CobÃ¡ http://miguel.leugim.com.mx

July 19, 2010

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

by Schwab,Wilhelm K

+10 In interest of full disclosure, some have argued that FFI poses a security risk; one nice solution that was proposed is a command line option to disable it. But making people work hard to connect to the outside world buys us nothing and should indeed be corrected. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gabriel Cuvillier Sent: Monday, July 19, 2010 2:20 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] A facility to launch external processes from Pharo should be provided by default on all platforms 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. 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-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 19, 2010

[Pharo-project] Fwd: [Pharo-users] Recent Submissions

by StÃ©phane Ducasse

Ben you should register to pharo-dev Give a way for people to be lazy 1- give them a way load simply your code Gofer new squeaksource: 'PharoTaskForces'; package: 'Tools-Browser'; load 2- publish your work in a separate package 3- propose a way to open it 4- Create a separate class so that we can play with it independently of the other and existing tools. Stef Begin forwarded message: > From: Benjamin Van Ryseghem <benjamin.vanryseghem(a)gmail.com> > Date: July 19, 2010 9:03:57 PM GMT+02:00 > To: pharo-users(a)lists.gforge.inria.fr > Subject: [Pharo-users] Recent Submissions > Reply-To: A friendly place where any question about pharo is welcome <pharo-users(a)lists.gforge.inria.fr> > > Hi everybody, > > > I'm a new Smalltalker tutored by StÃ©phane Ducasse who gave me the project to rewrite the "Recent Submissions" tool to improve the UI and the functionalities. > > I've already done a basic version posted in PharoTaskForces (the RecentMessageSet class in Tool-Browser) on squeaksource, so if anybody have ideas or advice, I'll thank him a lot > > > > > Benjamin Van Ryseghem > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

July 19, 2010

Re: [Pharo-project] about hex

by StÃ©phane Ducasse

Levente Now what hex should returns? 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

July 19, 2010

[Pharo-project] about hex

by stephane ducasse

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

July 19, 2010