February 2014 - Pharo-dev - lists.pharo.org

Authorize upArrow in binary symbols

by Nicolas Cellier

Though being reserved for return statements, the upArrow ^ could perfectly be accepted as a character composing a binary selector, like the verticalBar | already is. Indeed there is no ambiguity, since the return ^ is always prefixed, while a binary message never is... (well, except in the method source, but method source must begin with selector, it cannot begin with a return statement, so no ambinguity there neither...). I don't plan to use or add such selector in core Squeak/Pharo, but I think that it is important to allow a variety of selectors : it allows the most simple DSL : one using Smalltalk syntax (no need to define a new syntax, a new parser, etc...). If we did it for |, I don't see why we shouldn't for ^. Note that we recently also extended usage of - at any place in binary selectors (it was restricted to first position previously), though no core message is concerned so far. The main objection could be that a missing period before a return statement won't be reported, but interpreted as a message send... like in: x := a+b ^x But I don't think it's really a feature stopper. It's very easy to modify the old Compiler and shouldn't be that hard in Opal too. I'll try and push a prototype in Squeak inbox this evening. What do you think?

Feb. 24, 2014

Re: [Pharo-dev] New methods for the String class

by btc＠openinworld.com

Feb. 24, 2014

Re: [Pharo-dev] Multiple-selection drag-and-drop

by Martin Dias

I found a possible fix that needs review: https://pharo.fogbugz.com/f/cases/12985/Sometimes-multi-selection-is-lost-o… cheers, MartÃn On Sat, Feb 22, 2014 at 5:20 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > On Sat, Feb 22, 2014 at 5:04 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > > On Sat, Feb 22, 2014 at 4:53 PM, Benjamin > > <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > >> On 22 Feb 2014, at 16:40, Martin Dias <tinchodias(a)gmail.com> wrote: > >>> > >>> Mmmmmmm, now that I test it with a mouse instead of a trackpad, I see > >>> it's almost impossible to do not loose the multiple selection before > >>> starting the drag in a TreeModel. > >> > >> Why? > >> Here it works fine (at least as expected) > >> I > >> -click on the first element, > >> -shift click on the last one, > >> -click and drag > >> > >> and it works > >> > > > > Ohhh! I found how to reproduce it: if you start to drag in the bottom > > item, then it works; but if you start in another one, then > > multi-selection is lost. > > Another find: > When multi-selecting using control key (I'm on mac), then drag has to > start in the last selected item, otherwise it's list. >

Feb. 24, 2014

Re: [Pharo-dev] R: Morphic UI designer

by Pavel Krivanek

2014-02-23 10:09 GMT+01:00 Lorenzo Schiavina <lorenzo(a)edor.it>: > Hi Steff, > > > > may I ask why Phobos is not considered as a good candidate as a basis for > an interface designer? > It's simple. For example if you want to develop an application for tablets, XULRunner is not the right choice. The same for highly interactive multimedia applications etc. It's aimed on business applications with native look&feel. Pharo wants to provide own multiplatform UI with zoomable accelerated graphics. As the default option. Our tools should be independent on UIframework. That's why we have Spec. I haven't developed Phobos to provide the only right way how to render UI. In fact, classical GUI has the best days behind. On the other hand, Pharostill needs some way how to support it and XULRunner is interesting way how to do that and already working. Cheers, -- Pavel > I have experience with PARTS (which is the best application in the field I > have ever seen in ST environment) and I believe that it could be used as a > basis for tools of this kind. > > If anyone is interested in PARTS (included in VSE ST) as a model, I will > be pleased to send it. > > > > Lorenzo > > > > *Da:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org<pharo-dev-bounces(a)lists.pharo.org>] > *Per conto di *Pharo4Stef > *Inviato:* sabato 22 febbraio 2014 17:19 > *A:* Pharo Development List > *Oggetto:* Re: [Pharo-dev] Morphic UI designer > > > > > > On 22 Feb 2014, at 15:24, jannik laval <jannik.laval(a)gmail.com> wrote: > > > > Does it make sense to add energy on it ? > > Probably, we should investigate UIPainter. > > > > > > may be the first thing to do would be to convert some of the widgets to > work in Pharo with announcements. > > I did not have the time to verify but I did the following experience > > I built a simple naive browser using self changed:/updates > > then I wanted to rewrite it using Announcement only and it did not work > probably because some of our widgets > > are not done to be used with announcements (probably they expect changed....) > > > > so it may be the same with his widgets. > > > > Stef > > > > > > Jannik > > > > 2014-02-21 22:02 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl>: > > At the moment I'm moving, so I have very little time to do something about > it. > Current state is described in a thread from end of last year: > > > http://forum.world.st/have-a-question-for-morphic-Designer-in-pharo-td47313… > > Stephan > > > > > > -- > > ~~Jannik Laval~~ > Ãcole des Mines de Douai > Enseignant-chercheur > http://www.jannik-laval.eu > http://car.mines-douai.fr/ > > >

Feb. 24, 2014

New methods for the String class

by Daniela Meneses

Hi to all, As you may know I'm working on in some improvements for the String class. Until now I implemented some missing tests. Right now I'm looking forward to add new methods that could be useful based on Ruby API ( http://www.ruby-doc.org/core-2.1.0/String.html) These are a few of the methods that I'm planning to implement: - chomp(separator=$/) -> new_str - chop() -> new_str - ljust(integer, padstr='') ->new_str - next -> new_str - partition(sep) -> [head, sep, tail] Could you help to find out if these methods are already available for the String class? If you have any idea of new methods for the string class, will be really welcome. -- Cheers , Daniela Meneses

Feb. 24, 2014

Drag&drop on a button

by Martin Dias

Hi, I wonder if either there is something wrong in my code below, or if I found a bug in morphic or spec. I expect to get a halt when drag&dropping an item from the tree into the button but nothing happens: | buttonModel treeModel ui uiLayout | ui := DynamicComposableModel new. treeModel := ui newTree roots: (1 to: 15); dragEnabled: true; yourself. buttonModel := ui newButton label: 'Drop here'; dropEnabled: true; icon: Smalltalk ui icons smallAddIcon; action: [ self halt ]; acceptDropBlock: [ self halt ]; wantDropBlock: [ self halt ]; dragTransformationBlock: [ self halt ]; yourself. ui assign: treeModel to: #treeModel. ui assign: buttonModel to: #buttonModel. uiLayout := SpecLayout composed newColumn: [ :column | column newRow: #treeModel; newRow: #buttonModel height: ui class buttonHeight ]; yourself. ui openWithSpecLayout: uiLayout. Thanks, MartÃn

Feb. 24, 2014

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