- Pharo-dev - lists.pharo.org

Re: [Pharo-project] How to display an image from an external PNG/JPG file in a Morph?

by Alain Plantec

Hi Dimitry, (ImageMorph withForm: (ImageReadWriter formFromFileNamed: 'pharoLogo.jpg')) openInWorld Cheers Alain Le 10/01/2011 05:33, Dimitry Golubovsky a Ã©crit : > Hi, > > Maybe a silly question, but is there an example of displaying an image > from an external file in a Morph? > > A sample package/class source, or a wiki page would be fine. Or just a > step-by-step description of the process. > > I am guessing that I have to create a Form first (that is, from the > picture file), but could not find which method to use. > > Thanks for any suggestions. >

Jan. 10, 2011

[Pharo-project] bootstrapping Order ...

by James Ladd

Hi All, I'm wondering where I can find information or if anyone knows off hand what the order of bootstrapping would be if the image had to be created from scratch? As I see it, there are dependencies between Object -> Class and so forth. Rgs, James.

Jan. 10, 2011

[Pharo-project] How to display an image from an external PNG/JPG file in a Morph?

by Dimitry Golubovsky

Hi, Maybe a silly question, but is there an example of displaying an image from an external file in a Morph? A sample package/class source, or a wiki page would be fine. Or just a step-by-step description of the process. I am guessing that I have to create a Form first (that is, from the picture file), but could not find which method to use. Thanks for any suggestions. -- Dimitry Golubovsky Anywhere on the Web

Jan. 10, 2011

[Pharo-project] Using Open Sound Control with Pharo 1.1.1 one click

by Andy Burnett

Hello I am trying to create some simple controls for an OSX Quartz Composer application. The app supports Open Sound Control - basically UDP multicast commands. I managed to load the OSC package from squeak source using Pharo 1.0. But I couldn't get UDP to work - the system report a Prim Failure. I updated to 1.1.1 and OSC now fails to load, due to a syntax error. Before I dig into this any further, I need to know whether UDP is actually working under Pharo - searching the list archive showed messages saying it was broken, but the bug tracker doesn't show it as a bug. Can anyone enlighten me? Cheers Andy

Jan. 10, 2011

Re: [Pharo-project] new Cog VMs

by Eliot Miranda

Hi All, find new VMs in VM.r2344/<http://www.mirandabanda.org/files/Cog/VM/VM.r2344/> (SimpleStackBasedCogit) and VM.r2345/ <http://www.mirandabanda.org/files/Cog/VM/VM.r2345/> (StackToRegisterMappingCogit) and VMMaker-oscog-45. These fix a bug that could cause crashes when converting an interpreted method to a machine-code method on backward branch (i.e. when the Vm detects an interpreted method is looping). I hope there are no new issues with VM.r2344/<http://www.mirandabanda.org/files/Cog/VM/VM.r2344/> (SimpleStackBasedCogit). However, Matthew Fulmer has found that on linux the VM.r2343/<http://www.mirandabanda.org/files/Cog/VM/VM.r2343/> VM.r2345/ <http://www.mirandabanda.org/files/Cog/VM/VM.r2345/> (StackToRegisterMappingCogit) VMs crash immediately loading Squeak4.2-10856-beta.image. I can reproduce this but haven't had time to investigate. The StackToRegisterMappingCogit VMs do start up this image on Mac and Windows. Agan thanks for pounding on these. I may not be able to attend to the linux/StackToRegisterMappingCogit/Squeak4.2-10856-beta.image until next weekend. Apologies. best Eliot On Thu, Dec 30, 2010 at 6:02 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi All, > > I've released a new version of Cog that has a substantially improved > code generator along the lines of Peter Deutsch's HPS (VisualWorks) and > various of Ian Piumarta's VMs. These all use a simple tecnique to identify > constant references in bytecode and to support a register-based calling > convention. While this does produce faster code it tends to accelerate > low-level code much more than high-level code as you can see by the > following benchmarks: > > SimpleStackBasedCogit: [1 to: 100000000 do: [:i|]] timeToRun 691 > StackToRegisterMappingCogit: [1 to: 100000000 do: [:i|]] timeToRun 192 > 192 - 691 / 6.91 -72% > > SimpleStackBasedCogit: 0 tinyBenchmarks '753495217 bytecodes/sec; 64769127 > sends/sec' > StackToRegisterMappingCogit: 0 tinyBenchmarks '931756141 bytecodes/sec; > 128157989 sends/sec' > 931756141 - 753495217 / 7534952.17 -24% > 128157989 - 64769127 / 647691.27 -98% > > SimpleStackBasedCogit: [Compiler recompileAll] timeToRun 47013 (no > transcript > StackToRegisterMappingCogit: [Compiler recompileAll] timeToRun 43406 (no > transcript) > 43406 - 47013 / 470.13 -7.67234594686576 > > The status of this code is essentially beta. The test suite runs the same > on the new code generator as on the old, but I think there are still bugs > because I get the occasional transient error. I am therefore very > interested in any reproducible errors you can find. > > The VMs (http://www.mirandabanda.org/files/Cog/VM/VM.r2334/) contain a few > other important changes: > > - a bug fix to bytecode<->native pc mappng that produced incorrect results > for methods containing blocks with ^-returns in them. One symptom is > incorrect highlighting of the pc in the debugger, althoguh symptoms could be > much serious. > > - jitting interpreted methods on backward branches. Currently any > interpreted method that performs more than 20 backward branches will be > considered for JIT compilation and if it is suitable (default, <= 60 > literals) will be compiled to native code. > > - new callback support. I need to commit some changes to the Alien package > to provide access to this but essentially the VM's callback support is now > able to be ported to architectures with register-based calling conventions > (ARM, PowerPC, SPARC etc). I'll try and get the Alien code released soon, > and to back-port the changes to the standard VM before the end of the > holiday. > > One thing that is still /not/ fixed is the lack of a SoundPlugin on win32. > Apologies. I'll try and get a fix for this before the end of the holidays > too, but time might be too tight. There are other priorities such as > harmonising the standard and Cog VMs for the 4.2 release. > > best > Eliot > >

Jan. 10, 2011

Re: [Pharo-project] Generating ticket (was Re: Generators for Pharo Xmax wish))

by StÃ©phane Ducasse

Ralph go on code.google.com/p/pharo then select issue: then create a new one. Stef On Jan 9, 2011, at 7:37 PM, Ralph Boland wrote: >> The easiest way to get this code into pharo core is to create a mcz >> package, put it on PharoInbox on squeaksource and create a ticket in >> code.google.com/p/pharo referencing it and taggint it Fixed, this way >> St?phane or Markus can harvest it to the core image. > > I am clear on how to do this (I am not a Pharo user). > I went to: > code.google.com/p/pharo > and from there I went to > squeaksource.com/PharoInbox/feed.rss > and subscribed. But I don't see how to add any text to the site. > I assume that "ticket" is a bug report but I don't know how to generate > one for Pharo. > > Please send instructions on how to do the above. > > >> If the mcz package is overkill, then a simple fileout of the package in >> squeak attached to the ticket will do. > >> Maybe in the long term a project on squeaksource should be created (if >> not exists) and new changes to to it and from there pulled to squeak and >> pharo. > > I believe Andreas Raab originally created a project for generators on > squeaksource but it doesn't appear to be there now. Perhaps it was > removed once the generators package was incorporated into Squeak. > > > Ralph Boland >

Jan. 9, 2011

Re: [Pharo-project] Pharo sprint @ lille Friday 21 of January

by StÃ©phane Ducasse

pass the message around you that people should reply here so that we know which organization to set up. On Jan 9, 2011, at 7:07 PM, Benjamin Van Ryseghem wrote: > I'll be there ^^ > > > Ben > > 2011/1/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Hi guys > > we will have a pharo sprint at Lille Friday 21 of January. If you want to join let us know that we organize for the food. > The sprint will happen in our rooms at LIFL > http://rmod.lille.inria.fr/web/pier/contactr/ > > Stef >

Jan. 9, 2011

Re: [Pharo-project] [squeak-dev] Re: [Seaside-dev] Seaside and exception behaviour

by Julian Fitzell

Hi Andreas, A neat approach, but I don't think it quite works (yet, anyway). Although it has the correct behaviour when the exception action is invoked, it doesn't behave correctly for #defaultAction. According to 5.5.2.1 in the spec, "The #defaultAction method is executed in the context of the signaling environment." So, taking an example of an existing #defaultAction method that signals an exception: [ Error signal ] on: UnhandledError do: [ :ex | 'ANSI says so' ] returns 'ANSI says so' without your change but brings up a debugger with it. Julian On Sat, Jan 8, 2011 at 7:34 PM, Andreas Raab <andreas.raab(a)gmx.de> wrote: > Thanks for the test case. I've posted a possible fix for Squeak to the inbox > (Kernel-ar.540) but I'd like people to review the change first since it's a > fairly critical part of the system. I'd appreciate if someone could look at > the fix and comment on whether that's the sensible thing to do. > > Cheers, > Â - Andreas > > On 1/8/2011 6:02 PM, Julian Fitzell wrote: >> >> On Wed, Jan 5, 2011 at 8:15 AM, Paolo Bonzini<bonzini(a)gnu.org> Â wrote: >>> >>> On 01/05/2011 04:58 PM, mkobetic(a)cincom.com wrote: >>>> >>>>>> Â Here's maybe a bit more concise example. If you run the thing below >>>>>> in a workspace, >>>>>> Â it returns 'Squeak' in Squeak and 'VW' in VW >>>>>> >>>>>> Â [ Â [ Â Â Â [ Â Â Â self error: 'trigger error' >>>>>> Â Â Â Â Â Â ] on: ZeroDivide do: [ :ex | 'Squeak' ] >>>>>> Â Â ] on: Error do: [ :ex | 3 / 0 ] >>>>>> Â ] on: ZeroDivide do: [ :ex | 'VW' ] >>>>> >>>>> Â It returns 'Squeak' on GNU Smalltalk. Â This is consistent with my >>>>> Â analysis of Alan's snippet. Â Unfortunately I don't have at hand my >>>>> copy >>>>> Â of the standard. >>>> >>>> FWIW, Smalltalk/X returns 'VW' >>> >>> That's the correct behavior. Â The standard says the search should proceed >>> from the last exception handler that was created up to the oldest. >> >> Agreed. Â The ANSI standard seems quite clear about that: >> >> 5.4.3.3: "If signaling of an exception results in evaluation of action >> the evaluation will occur in the context of the handler environment." >> >> 5.5.2.1: "If a matching handler is found, the exception action of the >> handler is evaluated in the exception environment that was current >> when the handler was created and the state of the current exception >> environment is preserved as the signaling environment." >> >>> (That said, Squeak/gst's behavior is quite easy to justify, as stack >>> unwinding hasn't happened yet. Â I'll wait for this thread to settle >>> before >>> changing it in gst). >> >> But stack unwinding shouldn't need to happen until one of the #on:do: >> calls is actually ready to return. Until then, its all just searching. >> >> I think Squeak/Pharo's problem is that it doesn't maintain a first >> class "exception environment" as described by the glossary in the ANSI >> standard: "An abstract entity that is a LIFO list of exception >> handlers. An exception environment may be logically searched starting >> from the most recently "pushed" exception handler." >> >> Squeak/Pharo simply (ab)uses the context chain, walking it looking for >> the next handler (see the implementation of #signal, which always >> starts searching from thisContext). This works fine most of the time >> but not when you need to temporarily restore a previous exception >> environment. #handleSignal: does go to the effort of setting a >> handlerContext on the signaled exception before calling the action >> block. This is necessary to implement #pass, #isNested, and so on but >> would also need to be put somewhere that #signal could get at it to >> use as a starting point for the search. >> >> This seems like a squeak/pharo bug to me. I don't much feel like >> fixing it in Grease given that Grease is supposed to assume correct >> ANSI implementation as a pre-requisite. Perhaps we can broker a deal >> where Squeak/Pharo will fix this and VW (finally) fixes its signaling >> behaviour so we can drop GRError, etc. entirely. >> >> In the meantime, though, how would we fix the Seaside code assuming we >> had ANSI-correct exception handling implementations? >> >> Julian >> >> > > >

Jan. 9, 2011

[Pharo-project] Generating ticket (was Re: Generators for Pharo Xmax wish))

by Ralph Boland

> The easiest way to get this code into pharo core is to create a mcz > package, put it on PharoInbox on squeaksource and create a ticket in > code.google.com/p/pharo referencing it and taggint it Fixed, this way > St?phane or Markus can harvest it to the core image. I am clear on how to do this (I am not a Pharo user). I went to: code.google.com/p/pharo and from there I went to squeaksource.com/PharoInbox/feed.rss and subscribed. But I don't see how to add any text to the site. I assume that "ticket" is a bug report but I don't know how to generate one for Pharo. Please send instructions on how to do the above. > If the mcz package is overkill, then a simple fileout of the package in > squeak attached to the ticket will do. > Maybe in the long term a project on squeaksource should be created (if > not exists) and new changes to to it and from there pulled to squeak and > pharo. I believe Andreas Raab originally created a project for generators on squeaksource but it doesn't appear to be there now. Perhaps it was removed once the generators package was incorporated into Squeak. Ralph Boland

Jan. 9, 2011

Re: [Pharo-project] Gofer problem installing packages with the same name

by HernÃ¡n Morales Durand

Hi Lukas, 2011/1/9 Lukas Renggli <renggli(a)gmail.com>: > No, Gofer doesn't look in repositories you don't specify. However, it > uses and prefers your local package-cache if it contains a newer > version of your package (which is likely the case in your example). I see. I assumed that to distinguish a newer version corresponds to the right package, a package included meta-information about its source repositories or some fingerprint. > You can disable the package-cache by sending something like > #disablePackageCache to your Gofer instance (I don't have an image at > hand right now, but you find it in the code and documentation). > Thanks, it worked fine. > Gofer is part of Pharo and not maintained in my repository anymore. > This #update method should be removed it is not supposed to work > anymore. > > Lukas > > On Sunday, 9 January 2011, HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com> wrote: >> Hi list, >> I have some issues with Gofer, maybe already known. When I evaluate: >> >> Gofer new >> Â Â Â Â Â squeaksource: 'Subjectivity'; >> Â Â Â Â Â package: 'Subjectivity'; >> Â Â Â Â Â load. >> >> it seems that Gofer takes the first package named Subjectivity it >> founds which in this case is >> http://www.squeaksource.com/Decisionstrategy.html while I wanted to >> take it from http://www.squeaksource.com/Subjectivity.html (please see >> the screenshot). >> After then I've tried to update "Gofer upgrade" for a fix, but it >> seems it cannot connect to http://source.lukas-renggli.ch and then >> entered in an endless loop. Any hint? >> (Using Pharo1.2beta Latest update: #12294) >> >> Cheers, >> >> -- >> HernÃ¡n Morales >> Information Technology Manager, >> Institute of Veterinary Genetics. >> National Scientific and Technical Research Council (CONICET). >> La Plata (1900), Buenos Aires, Argentina. >> Telephone: +54 (0221) 421-1799. >> Internal: 422 >> Fax: 425-7980 or 421-1799. >> > > -- > Lukas Renggli > www.lukas-renggli.ch >

Jan. 9, 2011