June 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] Translating FileDirectory et al to FileSystem

by Sean P. DeNigris

We're getting there! I can't believe how much effort and progress there is already. One thing I've been noticing... when porting DirectoryEntry and subclasses to FileSystemDirectoryEntry, #name should be translated to #basename (otherwise, you get 'Directory Entry: ...', not the filename). Some of the updates (several authors) are going to have to be re-fixed because of this (I nabbed a few already). Also, FileDirectory>>pathName should become #fullName (which incidentally is pretty safe because FileDirectory>>fullName does the same thing). Cheers, Sean -- View this message in context: http://forum.world.st/Translating-FileDirectory-et-al-to-FileSystem-tp46360… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 22, 2012

Re: [Pharo-project] badDirectoryPath

by Sean P. DeNigris

It seems like the primitive is not returning enough context. badDirectoryPath is a catch-all for any error. For example, if you send #entries to aFileReference on a directory where you don't have enough permissions, you get #badDirectoryPath. Besides being misleading - the path is not really "bad" - it's hard to deal with the error because it's so general. For example, DiskStore>>directoryAt:ifAbsent:nodesDo: has a bug (http://code.google.com/p/pharo/issues/detail?id=6122) ... entry := Primitives lookupEntryIn: encodedPathString index: index. entry = #badDirectoryPath ifTrue: [ ^ absentBlock value ]. ... So if the entry exists but the primitive fails (e.g. not enough permissions), the absentBlock is evaluated. It's easy enough to fix, but how would you signal a helpful error? Cheers, Sean -- View this message in context: http://forum.world.st/badDirectoryPath-tp4635913p4636046.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 22, 2012

Re: [Pharo-project] New System Progress Bar

by Igor Stasenko

btw, about human readable.., i don't understand, why we don't have something as simple as: collection do: [... ] showingProgress: 'Processing collection' (1 to: 100) do: [ ...] showingProgress: 'Processing ' 1 to: 100 do: [ ...] showingProgress: 'Processing ' i don't care what happens inside, but this interface is IMO much simpler and straightforward: a user just adds showingProgress: at the end, and voila, his silent block now showing a progress. -- Best regards, Igor Stasenko.

June 22, 2012

Re: [Pharo-project] Where is the PBE VM?

by Sven Van Caekenberghe

On 21 Jun 2012, at 22:43, Camillo Bruni wrote: >>> I am seriously considering including the "Metacello Scripting API doc"[3] as the class comment for the Metacello class, but you have to admit that [3] is more readable than [4]. > > but it still reads fairly well even in the plain text format :) > >>> BTW, Markdown isn't the only markup syntax[5]...supporting one of the many would be sufficient.. > > indeed, I am somehow torn towards MarkDown (totally arbitrary choice I guess). > Unless someone comes up with a very convincing argument I'd stick with markdown :) I love Markdown as well: it is very simple, it remains readable as source text and it renders well to HTML. Sven

June 21, 2012

Re: [Pharo-project] Where is the PBE VM?

by Camillo Bruni

>> along these lines is anyone working on a Markdown[1] formatter for Pharo? PetitMarkdown <http://ss3.gemstone.com/ss/petitmarkdown.html> Yes I patched the existing parser to be more or less useful. but it was far from complete plus the old design did not really permit for the full markdown syntax :/ so damien started a new prototype which parses the basic blocks first and then goes into details. >> I am probably notorious for missing class comments, but I am more motivated to write class comments if I can produce nicely formatted comments[2]. so far igor used our old parser to create the NativeBoos documentation filled with interactive links to methods and classes plus decent formatting for source code and titles >> I am seriously considering including the "Metacello Scripting API doc"[3] as the class comment for the Metacello class, but you have to admit that [3] is more readable than [4]. but it still reads fairly well even in the plain text format :) >> BTW, Markdown isn't the only markup syntax[5]...supporting one of the many would be sufficient.. indeed, I am somehow torn towards MarkDown (totally arbitrary choice I guess). Unless someone comes up with a very convincing argument I'd stick with markdown :)

June 21, 2012

[Pharo-project] [update 2.0] #20151

by StÃ©phane Ducasse

20151 ----- - Issue 6119: Cursor keeps on blinking when changing position. Thanks Camillo Bruni. http://code.google.com/p/pharo/issues/detail?id=6119 - Issue 6118: Let a gofer refernce loads itself. http://code.google.com/p/pharo/issues/detail?id=6118 - Issue 6099: Deprecate #value: for system progress (was red cross during updates). Thanks Sean DeNigris. http://code.google.com/p/pharo/issues/detail?id=6099 - Issue 6120: Scriptloader needs some ci updates. Thanks ben and Stef :) http://code.google.com/p/pharo/issues/detail?id=6120

June 21, 2012

Re: [Pharo-project] Where is the PBE VM?

by StÃ©phane Ducasse

there is a markdown parser in petitparser made by damienP and CamilloB. But I do not know the status Stef On Jun 21, 2012, at 7:59 PM, Dale Henrichs wrote: > along these lines is anyone working on a Markdown[1] formatter for Pharo? > > I am probably notorious for missing class comments, but I am more motivated to write class comments if I can produce nicely formatted comments[2]. > > I am seriously considering including the "Metacello Scripting API doc"[3] as the class comment for the Metacello class, but you have to admit that [3] is more readable than [4]. > > BTW, Markdown isn't the only markup syntax[5]...supporting one of the many would be sufficient.. > > Dale > > [1] http://daringfireball.net/projects/markdown/syntax > [2] https://github.com/dalehenrich/metacello-work/blob/issue_10/repository/Meta… > [3] https://github.com/dalehenrich/metacello-work/blob/issue_10/docs/MetacelloS… > [4] https://raw.github.com/dalehenrich/metacello-work/issue_10/docs/MetacelloSc… > [5] https://github.com/github/markup/blob/master/README.md > ----- Original Message ----- > | From: "Sean P. DeNigris" <sean(a)clipperadams.com> > | To: pharo-project(a)lists.gforge.inria.fr > | Sent: Thursday, June 21, 2012 10:37:41 AM > | Subject: Re: [Pharo-project] Where is the PBE VM? > | > | > | Camillo Bruni-3 wrote > | > > | > but yeah, I am not much in favor of the PBE book... that is a > | > hell a lot of work to keep up to date... we should write more > | > example code > | > and more class comments!! > | > > | > | +100 for books in general. We need active essays! I've been working > | furiously on this and literate programming for Pharo. I've made a lot > | of > | progress, but often get bogged down in Morphic. I'm eager to see what > | Fernando comes up with as far as cleaning Morphic. I believe that if > | Morphic > | gets truly cleaned, we will see an explosion of creative new tools... > | > | -- > | View this message in context: > | http://forum.world.st/Where-is-the-PBE-VM-tp4635676p4635999.html > | Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > | > | >

June 21, 2012

Re: [Pharo-project] SystemAnnouncements issues

by Mariano Martinez Peck

On Thu, Jun 21, 2012 at 8:31 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > Hi, > > firstly a question: should SystemAnnouncements be part of the Pharo > Kernel? On one side it makes sense to have in there however we can > keep it unloadable. It seems that currently the only class in Pharo > Kernel that uses it is the PragmaCollector. > I think it is only a matter of time that you will need to include SystemAnnouncements in the system. SystemChangeNotifier is slowly being replaced by SystemAnnouncer. So at some point you will HAVE to include it in Kernel. So I guess you can already start including it :) > > There is one issue related to SystemAnnouncements. As you may see from > this trace - > https://ci.lille.inria.fr/pharo/view/Pharo-Kernel%202.0/job/Pharo%20Kernel%… > - it may happen that the announcements are sent to an obsolete class. > The SystemAnnouncemnets use weak bindings however the receiver becomes > obsolete, not nil. > I have seen similar problems. I was creating/removing (or something) with methods, and then I was removing the class (I was doing this on tests). The problem was that since the notifications were run in a fork, at the time RPackage tried to handle the event, the class was already obsolete and therefore there was an error... > > Cheers, > -- Pavel > > -- Mariano http://marianopeck.wordpress.com

June 21, 2012

Re: [Pharo-project] New System Progress Bar

by StÃ©phane Ducasse

Thanks sean! Thanks thanks! I never the too smart aspect of the value: And I already removed broken code that performed animation inside :) Looking at your changes now. Stef On Jun 21, 2012, at 4:14 PM, Sean P. DeNigris wrote: > To help explain the changes, here's a snippet from the fix to "Issue 6099: > Deprecate #value: for system progress (was red cross during updates)" > (http://code.google.com/p/pharo/issues/detail?id=6099) The API (see > SystemProgressItemMorph) is not set in stone, but it's already much less > confusing than the old pseudo-class implementation. Ultimately, I'd like to > move to announcements instead of exceptions to signal progress, and decouple > the progress model/view - maybe just [un]registering the progress morph to > enable/disable. > > The slice in the inbox for this issue should fix the "red cross during > updates" problem... > > MOTIVATION: > The old system progress worked like this (for example)... > > SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar | > 1 to: 100 do: [ :x | > bar value: x. > bar value: 'On iteration ', x asString. > (Delay forMilliseconds: 20) wait "Just to slow it down so we can see > what's going on" ] ]. > > * The work block ([ :bar | ... ] above) would accept one argument > * That argument (:bar above) would be a block, that would act as a > pseudo-class. Depending on what was passed to #value:, it would perform > different functions. Two are illustrated above: > - #value: aNumber; where aNumber is between the min and max of the > progress range -> Set the bar's current progress mark to that position. For > example, 'bar value: 50' above would show the operation half complete > - #value: aString -> Set the label of the progress morph to aString > > This was very confusing, so we created a real class, > SystemProgressItemMorph, which now gets passed to the work block, and has a > real API. So, for example, the following becomes: > > SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar | > 1 to: 100 do: [ :x | > bar current: x. > bar label: 'On iteration ', x asString. > (Delay forMilliseconds: 20) wait "Just to slow it down so we can see > what's going on" ] ]. > > As you can see, '#value: newValue' has become '#current: newValue', and > '#value: newLabel' has become '#label: newLabel'. > > One wrinkle is that some users were passing a nil-like block instead of the > the pseudo-class to suppress the system progress bar. For example: > informUserDuring: aBlock > aBlock value: [:string | ]. > > Above, [:string | ] would now cause a DNU when sent, for example, #current:, > which obviously blocks don't understand. So, these cases were changed like > so: > informUserDuring: aBlock > aBlock value: DummySystemProgressItem new. > > Where DummySystemProgressItem simply ignores all messages without signaling > an error > > -- > View this message in context: http://forum.world.st/New-System-Progress-Bar-tp4635912.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

June 21, 2012

[Pharo-project] SystemAnnouncements issues

by Pavel Krivanek

Hi, firstly a question: should SystemAnnouncements be part of the Pharo Kernel? On one side it makes sense to have in there however we can keep it unloadable. It seems that currently the only class in Pharo Kernel that uses it is the PragmaCollector. There is one issue related to SystemAnnouncements. As you may see from this trace - https://ci.lille.inria.fr/pharo/view/Pharo-Kernel%202.0/job/Pharo%20Kernel%… - it may happen that the announcements are sent to an obsolete class. The SystemAnnouncemnets use weak bindings however the receiver becomes obsolete, not nil. Cheers, -- Pavel

June 21, 2012