- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] SystemLogger unrevealed :)

by Pharo4Stef

I added this kind of description to the new version of the chapter yesterday. On 24 Feb 2014, at 11:53, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 23.02.2014 um 19:20 schrieb Pharo4Stef <pharo4Stef(a)free.fr>: > >> >> I would define >>> OPALCompilationLogEvent as a subclass of Log >> >> and add the information it wants and special behavior identify borken method. >> >> I added a description to the chapter and I updated the class comments to reflect that. >> > Ok. So the implementation can decide if a complex object is transport in the message instVar or if the log object is extended to carry more information. My point with asLog is just that you can easy the creation of the custom log classes. It would just work for > > MyLogThing class>>#logClass > ^ OPALCompilationLogEvent > > if you want to transport your object as the message or > > MyLogThing>>#asLog > ^ self class newLog > customField: self > > if it is supposed somewhere different. > > In any of those case you can access it with > > (myLogThingObject asLog > error; > tag: #opal) emit > > Just FYI, > > Norbert > >> >> On 23 Feb 2014, at 19:00, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> >>> Am 23.02.2014 um 18:54 schrieb Pharo4Stef <pharo4Stef(a)free.fr>: >>> >>>> >>>>> But I understand, that is not my point. >>>> >>>> Yes I saw it after sending and reading the other mails. >>>> This part was made by norbert and it was not obvious to me. >>>> Iâm adding the example to the chapter right now. >>>> >>> If it wasnât obvious can you give an example how the OPALCompilationLogEvent would work. Maybe we still have a dissonance here. Is OPALCompilationLogEvent a subclass of Log or ist the log message from opal put into the message of a log or even done with extension? >>> >>> Norbert >>>> >>>> >>>>> You just need to add a clear example to the docs to make your point, because now you don't, everything is just old school string messages. >>>>> >>>>> On 23 Feb 2014, at 18:41, Pharo4Stef <pharo4Stef(a)free.fr> wrote: >>>>> >>>>>> >>>>>> On 23 Feb 2014, at 13:32, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>> >>>>>>> >>>>>>> On 23 Feb 2014, at 12:23, Norbert Hartl <norbert(a)hartl.name> wrote: >>>>>>> >>>>>>>> One of the core ideas is âlogging objects and not stringsâ. >>>>>>> >>>>>>> I am missing a clear example of that though. >>>>>> >>>>>> >>>>>> sven when opal is writing to the transcript that there is an undeclared or a shadow I want to get a OPALCompilationLogEvent that I can query and ask to jump in the broken code. >>>>>> >>>>>>> I am wondering what the expect interface is, how difficult/easy it is to fit in a new object as log (event). >>>>>> >>>>>> In SystemLogger you have >>>>>> >>>>>> self handleConvertedLogEvent: (self convert: aLogEvent) >>>>>> >>>>>> and convert: can do what ever we want to convert an object into a string. >>>>>> Stef >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >

Feb. 24, 2014

Re: [Pharo-dev] SysLogSender / UDP

by GÃ¶ran Krampe

On 02/24/2014 12:52 PM, Damien Cassou wrote: > On Sun, Feb 23, 2014 at 8:40 PM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: >> logger := SysLogSender new addHost: 'localhost' port: 514. > > > is there anything listening on port 514? You might want to try with a > port greater than 1024. Quick googling: http://superuser.com/questions/131578/how-do-you-enable-syslogd-to-accept-i… So UDP port 514 is the standard port for syslogd, if enabled of course. regards, GÃ¶ran

Feb. 24, 2014

Re: [Pharo-dev] LargePositiveInteger indexIfCompact isZero (inconsistency)

by Martin Dias

On Mon, Feb 24, 2014 at 12:21 PM, ClÃ©ment Bera <bera.clement(a)gmail.com>wrote: > Hello, > > Try : > > Smalltalk compactClassesArray at: 5 put: nil. > LargePositiveInteger becomeUncompact. > LargePositiveInteger becomeCompactSimplyAt: 5. > > then: > > LargePositiveInteger indexIfCompact. > > is correct. > > Same script is needed for LargeNegativeInteger. > > Good! > I think this bug is due to the introduction of LargeInteger class in Pharo > 3 (common superclass of LargePositiveInteger and LargeNegativeInteger). > > Ok > Now this is strange that the script I gave you worked because if you look > at > TBehavior>>checkCanBeUncompact > "Certain classes cannot be uncompacted in CogVM. If you download VMMaker > and see the VM code, these are as defined by > StackInterpreter>>#checkAssumedCompactClasses and the ones that can't be > uncompacted are the following: " > ({ Array. LargeNegativeInteger. LargePositiveInteger. Float. > MethodContext } includes: self) > ifTrue: [ self error: 'Class ', self name, ' cannot be uncompact. ' ] > > I debugged "LargePositiveInteger becomeUncompact": it returns before sending #checkCanBeUncompact since #indexIfCompact is zero. So, it'd be enough with just: Smalltalk compactClassesArray at: 4 put: nil. LargeNegativeInteger becomeCompactSimplyAt: 4. Smalltalk compactClassesArray at: 5 put: nil. LargePositiveInteger becomeCompactSimplyAt: 5. > However it seems that it worked with #becomeCompactSimplyAt > > So we should add a test for compact classes consistency. Maybe in Slot's class builder. --- PS: I've found this method in Integer metaclass: initialize "Integer initialize" "Ensure we have the right compact class index" "LPI has been a compact class forever - just ensure basic correctness" (LargePositiveInteger indexIfCompact = 5) ifFalse:[ (Smalltalk compactClassesArray at: 5) ifNil:[LargePositiveInteger becomeCompactSimplyAt: 5] ifNotNil:[self error: 'Unexpected compact class setup']]. (LargeNegativeInteger indexIfCompact = 4) ifFalse:[ (Smalltalk compactClassesArray at: 4) ifNil:[LargeNegativeInteger becomeCompactSimplyAt: 4] ifNotNil:[self error: 'Unexpected compact class setup']]. (2 years old) the only senders in the image of #becomeCompactSimplyAt: --- MartÃn

Feb. 24, 2014

Re: [Pharo-dev] [OT] Where should menues go ...

by Sebastian Sastre

Excellent. Here is a visual way to perceive how Fittâs Law works: http://www.particletree.com/features/visualizing-fittss-law/ On Feb 23, 2014, at 10:30 AM, GermÃ¡n Leiva <leivagerman(a)gmail.com> wrote: > http://www.codinghorror.com/blog/2006/08/fitts-law-and-infinite-width.html > > > On Sun, Feb 23, 2014 at 12:10 PM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > On 23 Feb 2014, at 11:44, MartinW <wm(a)fastmail.fm> wrote: >> >> The difference of Pharo (and it's UI!) was what lured me into it, not what >> constituted a barrier :) And while i would also make a case for difference >> only for it's own sake, i think there are very good reasons for the pop-up >> menus. > > They are very good reasons for popup menus. > > The work menu is not one of them > > Popup menus should (mainly) be used to propose contextual options. > Now take a random menu in Pharo, and look for the items > that applies only in the current context. > > Thatâs also the reason why the menu are far too long. > > > Ben > > > > -- > GermÃ¡n Leiva > LeivaGerman(a)gmail.com

Feb. 24, 2014

Re: [Pharo-dev] SysLogSender / UDP

by Damien Cassou

On Sun, Feb 23, 2014 at 8:40 PM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > logger := SysLogSender new addHost: 'localhost' port: 514. is there anything listening on port 514? You might want to try with a port greater than 1024. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Feb. 24, 2014

Re: [Pharo-dev] ScrollPane vs. GeneralScrollPane

by Gary Chambers

Hi Sean. By "accurately" I mean without any added extra space around the contents. You should use #scrollTarget: to set the content of the scroll pane as a whole (the default content is the blue morph you mention). E.g. |work scroll| work := self newWorkAreaMorph. scroll := GeneralScrollPane new borderWidth: 0; color: Color transparent; hResizing: #spaceFill; vResizing: #spaceFill. scroll scrollTarget: work; on: #mouseDown send: #selectByHandFromScroller: to: self page. Or, assuming is in Pharo 2.0/3.0, the builder method. scroller := UITheme builder newScrollPaneFor: self newSettingsGroup. scroller fillStyle: scroller scrollTarget fillStyle; changeScrollerTableLayout; vResizing: #spaceFill; hResizing: #shrinkWrap. Regards, Gary ----- Original Message ----- From: "Sean P. DeNigris" <sean(a)clipperadams.com> To: <pharo-dev(a)lists.pharo.org> Sent: Friday, February 14, 2014 1:25 AM Subject: [Pharo-dev] ScrollPane vs. GeneralScrollPane > GeneralScrollPane's class comment says "A scroll pane that handles its > contents accurately". As opposed to what? Was it intended as a replacement > for ScrollPane, or does it cover a different case? > > Also, the examples show scrolling a single Morph that is too big for the > container, which is easy, but for a list requires creating an extra morph > (not a big deal). "GeneralScrollPane new scroller" returns a > TransformWithLayoutMorph, which is "A transform morph that allows the use > of > a layout policy to arrange submorphs". That sounds like I could do > something > like: > s := GeneralScrollPane new. > s scroller changeTableLayout. > (1 to: 50) do: [ :e | s scroller addMorphBack: (SimpleObjectMorph on: > e ) ]. > s openInWindow. > > Although it lays out the object morphs vertically in the scroll pane, > there > is a blue morph above them and the scroll bars only appear when the pane > is > smaller than this morph. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/ScrollPane-vs-GeneralScrollPane-tp4743443.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. >

Feb. 24, 2014

Re: [Pharo-dev] LargePositiveInteger indexIfCompact isZero (inconsistency)

by ClÃ©ment Bera

Hello, Try : Smalltalk compactClassesArray at: 5 put: nil. LargePositiveInteger becomeUncompact. LargePositiveInteger becomeCompactSimplyAt: 5. then: LargePositiveInteger indexIfCompact. is correct. Same script is needed for LargeNegativeInteger. I think this bug is due to the introduction of LargeInteger class in Pharo 3 (common superclass of LargePositiveInteger and LargeNegativeInteger). Now this is strange that the script I gave you worked because if you look at TBehavior>>checkCanBeUncompact "Certain classes cannot be uncompacted in CogVM. If you download VMMaker and see the VM code, these are as defined by StackInterpreter>>#checkAssumedCompactClasses and the ones that can't be uncompacted are the following: " ({ Array. LargeNegativeInteger. LargePositiveInteger. Float. MethodContext } includes: self) ifTrue: [ self error: 'Class ', self name, ' cannot be uncompact. ' ] However it seems that it worked with #becomeCompactSimplyAt 2014-02-24 11:33 GMT+01:00 Martin Dias <tinchodias(a)gmail.com>: > Hi, > > I found this comment in TBehavior>>indexIfCompact : > > "Verify if the compactClassesArray and indexIfCompact are coheren > Smalltalk compactClassesArray doWithIndex: > [:c :i | c == nil ifFalse: > [c indexIfCompact = i ifFalse: [self halt]]] > " > > Since it *does* halt, I rewrote to: > > | inconsistencies | > inconsistencies := OrderedCollection new. > > Smalltalk compactClassesArray doWithIndex: [ :class :index | > class ifNotNil: [ > class indexIfCompact = index ifFalse: [ > inconsistencies add: { class. index. class indexIfCompact } ]]]. > > inconsistencies."---> an OrderedCollection({LargeNegativeInteger. 4. 0} > {LargePositiveInteger. 5. 0})" > > I checked that in Pharo 2 they are consistent, so I guess this should be > fixed. > > I ignore deep vm internals so... how would you fix this? > > I tried to #becomeUncompact to then #becomeCompact again, but it didn't > work out-of-the-box. > > Cheers, > MartÃn >

Feb. 24, 2014

Re: [Pharo-dev] Pharo3.0-portable deserves some publicity

by Tudor Girba

+1 Doru On Mon, Feb 24, 2014 at 11:57 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On 24 Feb 2014, at 11:51, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > > > Hi, > > > > Why Pharo3.0-portable (formely Oneclick) isn't on > http://www.pharo-project.org/pharo-download > > > The original idea was to retire that: it is only good for the mac, on all > other platforms it > is just strange. > > Now if the download page has already 5 ways of downloading Pharo, we will > loose > 90% of all people visiting it. > > Marcus > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 24, 2014

Re: [Pharo-dev] Pharo3.0-portable deserves some publicity

by Marcus Denker

On 24 Feb 2014, at 11:51, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > Hi, > > Why Pharo3.0-portable (formely Oneclick) isn't on http://www.pharo-project.org/pharo-download > The original idea was to retire that: it is only good for the mac, on all other platforms it is just strange. Now if the download page has already 5 ways of downloading Pharo, we will loose 90% of all people visiting it. Marcus

Feb. 24, 2014

Re: [Pharo-dev] SystemLogger unrevealed :)

by Norbert Hartl

Am 23.02.2014 um 19:20 schrieb Pharo4Stef <pharo4Stef(a)free.fr>: > > I would define >> OPALCompilationLogEvent as a subclass of Log > > and add the information it wants and special behavior identify borken method. > > I added a description to the chapter and I updated the class comments to reflect that. > Ok. So the implementation can decide if a complex object is transport in the message instVar or if the log object is extended to carry more information. My point with asLog is just that you can easy the creation of the custom log classes. It would just work for MyLogThing class>>#logClass ^ OPALCompilationLogEvent if you want to transport your object as the message or MyLogThing>>#asLog ^ self class newLog customField: self if it is supposed somewhere different. In any of those case you can access it with (myLogThingObject asLog error; tag: #opal) emit Just FYI, Norbert > > On 23 Feb 2014, at 19:00, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> Am 23.02.2014 um 18:54 schrieb Pharo4Stef <pharo4Stef(a)free.fr>: >> >>> >>>> But I understand, that is not my point. >>> >>> Yes I saw it after sending and reading the other mails. >>> This part was made by norbert and it was not obvious to me. >>> Iâm adding the example to the chapter right now. >>> >> If it wasnât obvious can you give an example how the OPALCompilationLogEvent would work. Maybe we still have a dissonance here. Is OPALCompilationLogEvent a subclass of Log or ist the log message from opal put into the message of a log or even done with extension? >> >> Norbert >>> >>> >>>> You just need to add a clear example to the docs to make your point, because now you don't, everything is just old school string messages. >>>> >>>> On 23 Feb 2014, at 18:41, Pharo4Stef <pharo4Stef(a)free.fr> wrote: >>>> >>>>> >>>>> On 23 Feb 2014, at 13:32, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> >>>>>> >>>>>> On 23 Feb 2014, at 12:23, Norbert Hartl <norbert(a)hartl.name> wrote: >>>>>> >>>>>>> One of the core ideas is âlogging objects and not stringsâ. >>>>>> >>>>>> I am missing a clear example of that though. >>>>> >>>>> >>>>> sven when opal is writing to the transcript that there is an undeclared or a shadow I want to get a OPALCompilationLogEvent that I can query and ask to jump in the broken code. >>>>> >>>>>> I am wondering what the expect interface is, how difficult/easy it is to fit in a new object as log (event). >>>>> >>>>> In SystemLogger you have >>>>> >>>>> self handleConvertedLogEvent: (self convert: aLogEvent) >>>>> >>>>> and convert: can do what ever we want to convert an object into a string. >>>>> Stef >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >

Feb. 24, 2014