- Pharo-dev - lists.pharo.org

[Pharo-project] Slime and '#fixCallbackTemps possibly missing'
by Stan Shepherd Aug. 18, 2009

Aug. 18, 2009

Hi, one of the Slime error checks throws the warning '#fixCallbackTemps possibly missing'. Am I right in thinking I can ignore this in the Seaside one click image? Thanks ...Stan -- View this message in context: http://n2.nabble.com/Slime-and-%27-fixCallbackTemps-possibly-missing%27-tp3… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

2 3

[Pharo-project] Preference browser does not load from disk
by csrabak＠bol.com.br Aug. 18, 2009

Aug. 18, 2009

2 2

[Pharo-project] Question about MD5
by Mariano Martinez Peck Aug. 18, 2009

Aug. 18, 2009

Hi folks: Me and the rest of the team is developing SqueakDBX which is a driver to talk with major databases. However, I think the most persistence alternatives pharo has, the best. There is no better solution for every escenario. So, I am also trying to get the PostgreSQL native driver to work in Pharo. This package depends on Cryptography because of MD5. I know that there were added to Pharo packages like System-Hashing-core, System-Hashing-SHA1 and System-Hashing-MD5. However, the driver doesn't work yet. But adding this single method: ByteArray>>hex | stream | stream _ '' writeStream. self do: [ :each | stream nextPut: ('0123456789ABCDEF' at: each // 16 + 1); nextPut: ('0123456789ABCDEF' at: each \\ 16 + 1)]. ^ stream contents The driver works like a charm in Pharo without needing Cryptography package. As far as I remember there were no MIT problem with this package. Because of this those packages ( System-Hashing-core, System-Hashing-SHA1 and System-Hashing-MD5) were integrated in Pharo. So, can I add it? Thanks Mariano

4 18

Re: [Pharo-project] [croquet-dev] Re: [squeak-dev] Second LIfe plugin API
by Lawson English Aug. 18, 2009

Aug. 18, 2009

Howard Stearns wrote: > Cool. What do you have in mind? > > Do you have any experience with the QuickTime media plugin? How is it > in general? How is it for streaming sources? > > The model for coordinating plugin activity across clients was not > clear to me. E.g., if I fire up QuickTime for a movie, how do all > other clients in the sim (that happen to have the plugin installed) > get coordinated to the same place in the movie? > > > Howard Stearns > Qwaq: +1-650-331-1437 > mobile: +1-608-658-2419 > > The way it works right now (and in the future unless they change things), a land-owner can set a "parcel media" URL which is the URL to a streaming media server that will play on any local object that displays a certain texture. The plugin API extends that to allow for custom plugins to run, but only in the context of the parcel media URL texture. I can imagine many cases where a media plugin served from localhost might be useful. It should be possible to specify localhost as a valid url for media-on-a-prim (HUD at least) that is settable separately from, or as an alternative to, the parcel media URL. IOW, if I install a custom HUD with a localhost url as the parcel media url, I should be able to interact with a private plugin running/streaming on my own comp. E.G. a seaside server on localhost doing all sorts of spiffy things that I haven't thought of yet. The plugin API makes it easy to have a plugin be part of the second life world, as far as GUI is concerned. I'm trying to convince people to create another message/event mechanism to allow more direct interaction with the SL viewer. IE, use Squeak as a scripting plugin on the viewer side. One could use the media API to provide a GUI and use the events API to send commands for generic scripting of the SL viewer. Lawson

1 0

[Pharo-project] [lewis@mail.msen.com: Re: [Vm-dev] Fwd: Could not load VMMaker in 10315]
by David T. Lewis Aug. 18, 2009

Aug. 18, 2009

FYI. This problem was originally reported on the Pharo list earlier this year. The fix is now in VMMaker on SqueakSource. ----- Forwarded message from "David T. Lewis" <lewis(a)mail.msen.com> ----- Date: Tue, 18 Aug 2009 08:05:22 -0400 From: "David T. Lewis" <lewis(a)mail.msen.com> To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> Subject: Re: [Vm-dev] Fwd: [Pharo-project] Could not load VMMaker in 10315 VMMaker (from SqueakSource) can now be loaded into closure-enabled images. I was able to remove a couple of temp variables from the GeniePlugin primitive without affecting the logic. This was discussed on several lists back in May. The fix is in VMMaker-dtl.135 on SqueakSource, and is documented in Mantis http://bugs.squeak.org/view.php?id=7384. Dave On Mon, May 25, 2009 at 10:37:15PM -0400, David T. Lewis wrote: > > On Mon, May 25, 2009 at 11:06:10AM -0700, Eliot Miranda wrote: > > > > On Mon, May 25, 2009 at 7:40 AM, David T. Lewis <lewis(a)mail.msen.com> wrote: > > > > > > > > On Sun, May 24, 2009 at 01:44:52PM -0700, Eliot Miranda wrote: > > > > > > > > 3. refactor the GeniePlugin method into an outer args parser and an inner > > > > engine method and solve the problem. Since VMMaker will inline anyway > > > this > > > > shouldn't make performance worse. I haven't done this because I'm not > > > the > > > > author and it is quite a complex method. > > > > > > This sounds like the right thing to do, regardless of what may change > > > in the compiler(s). > > > > > > +1 > > > > Well unfortunately the refactoring turns out to be easier said than done. > At least it was easier for me to say it than it was for me to do it. > > I made a naive attempt to split the primitive into smaller methods, but this > just ended up trading off too many things on the stack for too many arguments > in an argument list. > > The method temp variables could be changed to be instance variables. This > would probably work fine for any current VMs (not sure about Hydra), but > it does not pass the smell test IMO. > > I suspect that Nathaniel Schaerli knew what he was doing when he wrote > this primitive, and I most certainly do not, so I don't expect that I will > make much further progress on this front. > > Dave ----- End forwarded message -----

2 1

[Pharo-project] [ANN] prebuild PharoCore-1.0-10414-BETA
by Marcus Denker Aug. 18, 2009

Aug. 18, 2009

Hi, To save time... https://gforge.inria.fr/frs/download.php/22770/PharoCore-1.0-10414-BETA.zip Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

3 2

[Pharo-project] Bug or remnant to be stripped out?
by csrabak＠bol.com.br Aug. 18, 2009

Aug. 18, 2009

3 3

[Pharo-project] System Window and OB model
by Fernando olivero Aug. 18, 2009

Aug. 18, 2009

Quitting a system/hierarchy browser opened with the ToolSet, fails to inform the close to the model OB browser . For example in the following code 1 doesnt get explored | window | window := ToolSet browse: Set selector: anyOne. window model announcer observe: OBCloseRequest do:[:ann| 1 explore ]. Did anybody had this problem before? Or solved it already? Fernando

1 0

Aug. 18, 2009

Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: August 17, 2009 8:09:25 PM CEDT > To: Henrik Johansen <henrik.s.johansen(a)veloxit.no> > Cc: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>, Marcus Denker <denker(a)acm.org > >, John McIntosh <johnmci(a)smalltalkconsulting.com> > Subject: Re: [Pharo-project] SequenceableCollection do: causes GCs > with closure bytecodes > > > > On Mon, Aug 17, 2009 at 7:02 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > > > Begin forwarded message: > > From: Henrik Johansen <henrik.s.johansen(a)veloxit.no> > Date: August 17, 2009 3:21:53 PM CEDT > To: Pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] SequenceableCollection do: causes GCs with > closure bytecodes > Reply-To: Pharo-project(a)lists.gforge.inria.fr > > Something I noticed when looking at ByteArray>>hex, anyone know the > reason why there's GC going on in do: with closure images, but not > using the old bytecodes? > > Because with the old bytecodes a block activation simply reuses the > BlockContext allocated to implement the block whereas with the new > bytecodes a block activation allocates a new context. The stack VM > reduces context allocation markedly and so simple examples like the > below won't allocate. In the stack VM context allocation is > deferred until the context object is actually used. Contexts are > allocated on process switch, when a block is created or when > thisContext is used. > > HTH > > Even with no closed-over variables in the block, it seems it creates > extra fodder for the Garbage collector... > > Is it something the stack VM / Improved Garbage Collector will change? > > Cheers, > Henry > > Simple test: > intArray := (1 to: 10000000) asArray. > TimeProfileBrowser onBlock: [intArray do: [:ix | ix yourself]] > (It's not due to sampling overhead, Time millisecondsToRun: return > similiar runtimes) > > Without closures (I used 250): > -941 tallies, 965 msec. > **GCs** > incr 4 totalling 0ms > > With closures (I used 414): > -1938 tallies, 1938 msec. > **GCs** > inc 2510 totalling 614ms > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

1 0

[Pharo-project] Problem with Author
by Mariano Martinez Peck Aug. 17, 2009

Aug. 17, 2009

Hi folks: I think I found a little bug with the Author refactor. To reproduce: 1) Open Monticello browser 2) select a package you modified something, select a repository and press save 3) The popup asking you the full name and surename is opened. The thing is that if you press cancel, it closes the popup but another one is opened :( yo have no other choice that put "ok" Can anyone reproduce this ? If so, I'll open a bug ticket. Best, Mariano

4 12