- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Announcements in core images?

by StÃ©phane Ducasse

>From our side announcements are really important and should replaced a lot of events. On Jan 7, 2011, at 7:44 PM, Janko MivÅ¡ek wrote: > Hi both Squeakers and Pharoers, > > What is a status of Announcements package as part of core images? Are > they already there and, are they compatible, and if not, what are the > differences? > > Announcements are namely very important and elegant way of event > notifications based on publish/subscribe pattern. And they are portable, > which is very important for us, doing cross platform frameworks like > Aida, Seaside, etc. > > Therefore I'd really like to see Announcements included in all > Smalltalks by default and at least on API level as same as possible. > > Best regards > Janko > > > -- > Janko MivÅ¡ek > AIDA/Web > Smalltalk Web Application Server > http://www.aidaweb.si >

Jan. 8, 2011

Re: [Pharo-project] About using pragma for help like in setting

by StÃ©phane Ducasse

On Jan 7, 2011, at 5:22 PM, Torsten Bergmann wrote: > Dont confuse this, marking with <systemHelp> does not > mean you mark a method that returns a string and it > magically appears in the system help. > > This pragma is used to mark "help types" that should be > included in the SystemHelp. Classes marked with this > pragma are converted to to a help topic (#asHelpTopic) > and using subtopics for SystemHelp. > > This allows to easily "register" own help types like the > WikiStyleHelp. So this pragma is for people WHO WISH TO > EXTEND the help system itself (for new syntaxes, new help > contents sources, ... without patching it). > > This pragma is NOT FOR END USERS who want to write help contents. > > There is no difference since issue #3511 is integrated since > CustomHelp is the only provider of <systemHelp> so for. > Anything thats changed is the way SystemHelp (which is used > as default in HelpBrowser) queries for its roots. > > If you load the WikiStyleHelp you have another provider > of system help. > > Your scenario is different: > =========================== > - you want to write help contents that should load > in 1.1. and 1.2 and display at least in 1.2 > > > If it is OK for you to have a special help package > with the dependency on the help framework: > => use a CustomHelp subclass since this is supported in > 1.1. and 1.2 (loads and displays in both) > > If this (dependency) is a "no-go" then describe it using > the <wikiStyle> pragma do you have an example? HelpSystem looks too complex for me > > => it is loadable in both, but not displayed in both > => it will only appear in 1.2 if we either integrate > "WikiStyleHelp" into core or dev image or you load > the wiki style help extension it with your soup config > > Thats why I would like to see Alains idea pushed into 1.2. > (either as part of Help system in 1.2-core or as an help > extension package in 1.2-dev). which idea?

Jan. 8, 2011

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken

by Nicolas Cellier

2011/1/7 <csrabak(a)bol.com.br>: > > I will take this as meaning "I agree that Object>>copyFrom: is ambiguous..." > > If I misunderstood you, please feel free to correct. > > OTHO, as it is not explicitly written, I would like to understand your > stance on having this method name as a shorcut to > copyFrom: start to: (self size). > I don't think it's a good idea for backward compatibility reasons. Changing the semantics of #copyFrom: is worse than just deprecating the message. Do we really need this message ? For porting a package from another dialect ? > > I do agree 100% on this. Â However, there is a rub: > > aComplicatedName copyFrom: pocnu to: kraja. > > What can they be? Â As Smalltalk is dynamic even if you could see the > > |pocnu kraja| > . > . > . > you'll probably would need to see the implementers of the code that attribute > values to these (say) local variables. > Of course, one can always obfuscate its code, and the naming of these variable is well chosen with this respect. > > Again I think this is a reasoning that only can be explained due being > too comfy in our crib: > > Put this stub of code in a book (especially if the dead tree variety) and > claim that it is only a 'browsing of sender' away and you will understand > WHY the whole thread is not that much "ubuesque" as it seemed at first... > We can perfectly write a book explaining these selectors. Just group the selectors (copy copyFrom:to: etc..), explain copy vs partial copy, and explain theses selectors are in the ANSI standard API. 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. > > The semantics of copyFrom:to: are not the issue. The issue as is written > in the issue tracker _and_ the subject line is the semantics of copyFrom: > Agree, but i was seeing this thread derivate a bit. >> Â So no, Â I don't Â need to Â add a Â copy prefix Â to this >> message, and no i don't really care for a higher homogeneity. >> Â If we change Â a few missnamed selectors here Â and there, that's OK, >> but Â if Â we change Â a Â large amount Â of Â Kernel Â messages with Â many >> senders, it's a Â recipee for Pharo rejection, because Â we would make >> developer's life a hell for no valid reason. > > Or not! There is no reason why a newer "kernel" be created and if the usage > of it be so compelling or productive or practical or ....<put your favorite > marketing word> that it takes over the present state of affairs in the > usage of Smalltalk, why not!? > Well, we have to balance pros and cons of changing, especially in the kernel. > -- > Cesar Rabak > >

Jan. 8, 2011

Re: [Pharo-project] Adding hudson links from pharo webpage?

by Mariano Martinez Peck

On Fri, Jan 7, 2011 at 10:41 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > I would not have thought to put it there, but it's a good idea. I think > there should also be a link on the download section?? > > Exactly. THis is why I didn't even check in Community. It would have a section under download or something like this. Cheers Mariano > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Tudor Girba [ > tudor.girba(a)gmail.com] > Sent: Friday, January 07, 2011 1:53 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Adding hudson links from pharo webpage? > > Currently, the link is here: > http://pharo-project.org/community > > Cheers, > Doru > > > On 7 Jan 2011, at 19:22, Mariano Martinez Peck wrote: > > > Now that hudson seems to be working fine, I think it is a good moment to > link hudson links from the pharo website. > > > > cheers > > > > mariano > > -- > www.tudorgirba.com > > "The coherence of a trip is given by the clearness of the goal." > > > > > > >

Jan. 8, 2011

Re: [Pharo-project] wiki style help

by Alain Plantec

Hi all, very cool, thanks Torsten. Now, I think it's better to wait 1.3 because 1.2 is almost ready ... and I would use $! instead of $= as section marker to keep Pier compatibility. Cheers Alain Le 07/01/2011 14:16, Torsten Bergmann a Ã©crit : > 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. > > > > > > >

Jan. 8, 2011

[Pharo-project] Origins [poll] Summary

by Miguel CobÃ¡

Jan. 8, 2011

Re: [Pharo-project] Including Zinc HTTP Components in Pharo 1.2 Dev ?

by Guillermo Polito

As long as we don't remove HTTPSocket from scratch until two versions from now I see no problem :). On Fri, Jan 7, 2011 at 6:54 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > > On Jan 7, 2011, at 20:10 , Sven Van Caekenberghe wrote: > > > > > On 07 Jan 2011, at 13:58, StÃ©phane Ducasse wrote: > > > >> I was just reading the code with olivier auverlot. > >> I would love to have a small if possible replacement to the HTTPSocket. > > > > There really is a lot of cleanup to do. > > > > The key/core replacement of HTTP client functionality is done, but > HTTPSocket does so much stuff in such bizar ways that it will require a > concerted effort of many people to clean it up. > > I guess that a lot of stuff isn't needed anymore and hence doesn't need to > be reimplemented (?). We could deprecate such methods (or just delete them) > and if later we figure some are really needed we can put them back again. > I've quickly browser the references to HTTPSocket in PharoCore and there are > not too many complicated ones, as far as I can tell. > > Adrian >

Jan. 8, 2011

Re: [Pharo-project] [Moose-dev] Re: What feature you want to see in Mondrian

by Alexandre Bergel

Ok... I will see what can be done Alexandre On 7 Jan 2011, at 20:23, Tudor Girba wrote: > Here are my wishes in order of preferences: > > http://code.google.com/p/moose-technology/issues/detail?id=437 > http://code.google.com/p/moose-technology/issues/detail?id=398 > http://code.google.com/p/moose-technology/issues/detail?id=450 > http://code.google.com/p/moose-technology/issues/detail?id=113 > > :) > > Cheers, > Doru > > > On 7 Jan 2011, at 21:26, Alexandre Bergel wrote: > >> Hi! >> >> I am willing to spend some time on Mondrian the coming weeks. I would like to know what are the feature/issue what are the most pressing for you? >> >> http://code.google.com/p/moose-technology/issues/list?can=2&q=Mondrian&cols… >> >> Lazy edges? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Not knowing how to do something is not an argument for how it cannot be done." > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 8, 2011

Re: [Pharo-project] [Vm-dev] Problem restarting contexts in Cog 2341

by Eliot Miranda

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

Jan. 8, 2011

[Pharo-project] Issue 3520 in pharo: Workspaces do not recognize previously evaluated temps

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3520 by sean.p.denigris: Workspaces do not recognize previously evaluated temps http://code.google.com/p/pharo/issues/detail?id=3520 Pharo image: Pharo-core Pharo core version: Pharo1.2beta Latest update: #12294 Virtual machine used: Mac 4.2.5 Steps to reproduce: 1. Type "window := SystemWindow new openInWorld." in a workspace. 2. DoIt that line 3. An "Unknown variable" dialog pops up This is a workflow-killer.

Jan. 8, 2011