- Pharo-dev - lists.pharo.org

[Pharo-project] Using Open Sound Control with Pharo 1.1.1 one click
by Andy Burnett Jan. 10, 2011

Jan. 10, 2011

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

1 0

Re: [Pharo-project] [squeak-dev] Re: [Seaside-dev] Seaside and exception behaviour
by Julian Fitzell Jan. 9, 2011

Jan. 9, 2011

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

1 0

[Pharo-project] Gofer problem installing packages with the same name
by HernÃ¡n Morales Durand Jan. 9, 2011

Jan. 9, 2011

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.

2 2

[Pharo-project] wiki style help
by Torsten Bergmann Jan. 9, 2011

Jan. 9, 2011

Hi, Nice idea, I like the "wiki help description" for three reasons: - its pragma based AND allows for definition of structured books (so Lukas should be satisfied since he can define content without dependency on help system) - it allows us to reuse existing swiki contents (if the full syntax is supported we can query existing swikis!) So it is a nice idea and would be a good addition. I reworked Alains code to better fit the pluggable architecture of the HelpSystem framework (now using a builder): Use an updated 1.2 core image, code is attached 1. File in "Foo.st" (which defines a simple help description) => no dependency on any help system 2. First I added a registration mechanism (pragma <systemHelp> so one can add own help types to the system help (the one that appears when you open the default help browser) => load "AddToSystemHelpFix.1.cs" => at least this fix should go into Core 1.2, so no ugly hacks are necessary to appear in the default help browser I added a now fixed issue for core 1.2 on: http://code.google.com/p/pharo/issues/detail?id=3511 3. I reworked Alains code so it uses a WikiStyleHelpBuilder (similar to the other builders) and a WikiStyleHelp as a new help type => see WikiStyleHelp.5.cs => if we agree on this we can integrated it into core too, currently it is in an own class category/package => "HelpBrowser openOn: WikiStyleHelp" will show all contents defined using the wiki style syntax, so only the one defined in class Foo appears => "HelpBrowser open" will show all help in the system (including the ones defined in Foo) => since it uses the new registration mechanism (see 2. above) all these topics will also appear in the help browser that is accessible from the menu I would vote for adding this to core 1.2 too. It's additional, nothing should break. What do you all think... And thanks Alain for the idea and initial code!!! Have fun T. -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

3 3

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken (pharo@googlecode.com)
by Stephan Eggermont Jan. 9, 2011

Jan. 9, 2011

Nicolas wrote: >Then group the selectors (first, first: etc..), explain that they are >extensions, and don't need a copy prefix, because anyway most messages >will do a copy. You are aware first doesn't copy, do you? The explanation should be that you always have to take a look at the implementation to see if it copies or not (or sometimes), and explain when it doesn't matter (small integers, characters). Stephan

4 5

[Pharo-project] 4 days sprints in february
by StÃ©phane Ducasse Jan. 9, 2011

Jan. 9, 2011

Hi guys we are brainstorming with alain plantec to organize a sprint at roscoff (close to brest - excellent sea food). The set up would be: - 21 - 24 of february - this is holiday time here. I will rent a house with the kids there. - we can get access to a room for 450 Euros (break included). - the hosting is 50 Euros per day breakfast included - lunches are about 15 euros. So are some of you interested by participating. We could ask some sponsoring to ESUG. http://maps.google.fr/maps?client=safari&rls=en&q=roscoff&oe=UTF-8&redir_es… http://www.google.fr/images?client=safari&rls=en&q=roscoff&oe=UTF-8&redir_e… Stef

1 0

[Pharo-project] About preloaded packages
by StÃ©phane Ducasse Jan. 8, 2011

Jan. 8, 2011

Hi guys I would really like that pharo-dev does not contain too many libraries pre loaded (for example XMLSupport). I would favor push metacello so that in one click people can load what they want. Stef

11 19

Re: [Pharo-project] [Vm-dev] Problem restarting contexts in Cog 2341
by Eliot Miranda Jan. 8, 2011

Jan. 8, 2011

Hi All, find new VMs in VM.r2342/<http://www.mirandabanda.org/files/Cog/VM/VM.r2342/> (SimpleStackBasedCogit) and VM.r2343/ <http://www.mirandabanda.org/files/Cog/VM/VM.r2343/> ( StackToRegisterMappingCogit). 2343 seems fine but I appear to have introduced a regression into 2342. The 2343 VMs fix both of the bugs mentioned by Matthew and Yoshiki: This now evaluates to nil as intended: | a | a := false. [a ifFalse: [Error signal]] on: Error do: [:ex | a := true. ex retry] This no longer provokes a must-be-boolean error: BooleanArrayUser new loop1 As usual I'm very grateful for you pounding on these (ok, at least the 2343 VM :) ). best Eliot On Fri, Jan 7, 2011 at 10:10 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi Matthew, Hi Yoshiki, > > > thanks very much for this. I have a fix which I should be able to roll > out this evening or tomorrow. The problem was that the run-time code that > assigns inst vars of contexts was not preserving the register holding the > receiver although the code generator thought it was. So in > MethodContext>>#privRefresh a subsequent reference to a context inst var > failed because the register assumed to be holding the context got trashed. > There was another bug which caused the code generator's "simulation stack" > (its main optimization data structure) to be off by one for context inst var > assigns. Hopefully these two fixes will fix Yoshiki's bug also. Yoskhiki, > do you have a more reliable way of reproducing that bug? > > best > Eliot > > On Thu, Jan 6, 2011 at 6:40 PM, Matthew Fulmer <tapplek(a)gmail.com> wrote: > >> >> On Thu, Jan 06, 2011 at 09:27:14PM -0500, Matthew Fulmer wrote: >> > >> > In Cog release 2341, as distributed at >> > http://www.mirandabanda.org/files/Cog/VM/VM.r2341/ >> > >> > this causes an MNU. It should evaluate to true: >> > >> > | a | a := false. [a ifFalse: [Error signal]] on: Error do: [:ex | a := >> true. ex retry] >> >> actually it should evaluate to nil >> >> -- >> Matthew Fulmer (a.k.a. Tapple) >> > >

2 1

[Pharo-project] TODO 1.2
by Marcus Denker Jan. 8, 2011

Jan. 8, 2011

1) Core: - Failing Tests: 8 https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/lastCompleted… - Open Bug Tracker entries: 15 http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2 2) Full: - Failing tests: 8 + 11 https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/lastCompletedBuild/t… - Open Bug Tracker entries: 13 http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2-DevImage -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

[Pharo-project] Including Zinc HTTP Components in Pharo 1.2 Dev ?
by Sven Van Caekenberghe Jan. 8, 2011

Jan. 8, 2011

Hi, Maybe I am a bit late with this question, I also don't know who makes the decision, and it is probably external people who have to make the judgement, but would it be possible and/or a good idea to include Zinc HTTP Components into Pharo 1.2 Dev ? In any case, the code is in good shape, works on 1.2, has a reasonable number of tests, has comments, is pretty small and elegant. Whether or not to load the Zinc-Patch-HTTPSocket package is another question. This package patches (destructively overwrites) class methods in HTTPSocket, redirecting them to ZnHTTPSocketFacade, effectively steering all HTTP client access in your Smalltalk image through Zinc HTTP Components. This has been working for me for months, but my usage is certainly not universal. So maybe this should remain an option. I would especially like to expose this code to more people to get more feedback. I am also willing to keep on supporting the code. What do you think ? Sven

7 17