October 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Pillar for 30 gone the way of the dodo on the CI

by stepharo

> wellâ¦ Iâm with Marcus here: the real problem is that we shouldnât use the CI as a repository for download images. Yes I understand but now I have to edit my scripts and find what it not working. > Instead, I would keep them in a public file server (pretty much the same we do with Pharo, we do not keep all builds (or versions) in the CI, but all history is available at files.pharo.org. > And we cannot keep this indefinitely because of many reasons (and the fact that INRIA servers are not infinite is one important). > > So, maybe we should make community available some files.pharo.org/contribution where jobs can upload the built versions (not the full history, but at least stable and development versions? would be nice. > that way people can still find their versions and we can reduce a bit the weight of pharo-contribution? > > cheers, > Esteban > >> On 03 Oct 2015, at 09:15, stepharo <stepharo(a)free.fr> wrote: >> >> >>>>> We removed the Pillar job for Pharo 3 because we introduced an new >>>>> feature not backward compatible. >>>> Why is that a reason to remove the build? You have a configuration, >>>> don't you? >>> I would suggest: move to a separate job that is run much less often >>> and doesn't keep so many old artifacts. That makes it easier to get old stuff running again. >> + 10000 >> >> >> > >

Oct. 3, 2015

Re: [Pharo-users] Pillar for 30 gone the way of the dodo on the CI

by Esteban Lorenzano

wellâ¦ Iâm with Marcus here: the real problem is that we shouldnât use the CI as a repository for download images. Instead, I would keep them in a public file server (pretty much the same we do with Pharo, we do not keep all builds (or versions) in the CI, but all history is available at files.pharo.org. And we cannot keep this indefinitely because of many reasons (and the fact that INRIA servers are not infinite is one important). So, maybe we should make community available some files.pharo.org/contribution where jobs can upload the built versions (not the full history, but at least stable and development versions? that way people can still find their versions and we can reduce a bit the weight of pharo-contribution? cheers, Esteban > On 03 Oct 2015, at 09:15, stepharo <stepharo(a)free.fr> wrote: > > >>>> We removed the Pillar job for Pharo 3 because we introduced an new >>>> feature not backward compatible. >>> >>> Why is that a reason to remove the build? You have a configuration, >>> don't you? >> >> I would suggest: move to a separate job that is run much less often >> and doesn't keep so many old artifacts. That makes it easier to get old stuff running again. > > + 10000 > > >

Oct. 3, 2015

Re: [Pharo-users] Morph: event handler on wrong morph/submorph

by Federico.Balaguer

Yes! On Oct 3, 2015 3:57 AM, "stepharo [via Smalltalk]" < ml-node+s1294792n4853384h52(a)n4.nabble.com> wrote: > Hi federico > > could you > - show it to damien when he will come to Laplata? > - could you produce a small video because I would like to share it > with other teachers? > > Stef > > Le 28/9/15 18:59, Federico.Balaguer a Ã©crit : > > > Hello, > > > > I found a problem with BotArena > > (http://smalltalkhub.com/#!/~FedericoBalaguer/BotArena) on Pharo 4. > > > > BotArena is an interactive robot simulation environment that we use in > my > > university to teach OOP basics. BotArena was developed as an > instantiation > > of BOSS (http://smalltalkhub.com/#!/~CAR/BOSS/) > > > > BotArena (as well as BOSS) has a window (Morph) that has three buttons > and a > > grid view that is subclass of BorderedMorph. The GridView can handle > > RedButtons, a click on the grid adds a new robot to the simulation. > > > > The problem that raised on Pharo4 is that, after a RedButton event, any > > event (focus to another pharo window or clicking on one of the buttons > of > > BotArena) will be handled by the GridView. > > > > It seems like the GridView retains the focus after the (first) RedButton > > event was handled. > > > > Could someone help me to sort this one out? > > > > Thanks! Federico > > > > > > > > -- > > View this message in context: > http://forum.world.st/Morph-event-handler-on-wrong-morph-submorph-tp4852370… > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://forum.world.st/Morph-event-handler-on-wrong-morph-submorph-tp4852370… > To unsubscribe from Morph: event handler on wrong morph/submorph, click > here > <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…> > . > NAML > <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > -- View this message in context: http://forum.world.st/Morph-event-handler-on-wrong-morph-submorph-tp4852370… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Oct. 3, 2015

Re: [Pharo-users] Pillar for 30 gone the way of the dodo on the CI

by Stephan Eggermont

On 03-10-15 09:16, stepharo wrote: > So let us archive it but now my scripts are broken. If we want the old scripts to continue working, instead of creating a new (old) job for it we would need some mechanism to tell the build matrix in more detail what should happen to which build: only build nightly/weekly, and keep just a few artifacts Stephan

Oct. 3, 2015

Re: [Pharo-users] IS there TypePlug for Pharo or similar type annotation tool?

by Marcus Denker

> On 02 Oct 2015, at 20:50, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > What options do we have in terms of type annotations in Pharo? > > I stumbled upon TypePlug this https://marcusdenker.de/talks/08ParisTypes/08ParisTypePlug.pdf <https://marcusdenker.de/talks/08ParisTypes/08ParisTypePlug.pdf> (or rather this http://scg.unibe.ch/archive/masters/Hald07a.pdf <http://scg.unibe.ch/archive/masters/Hald07a.pdf> ) > > which enabled type annotation for Squeak such as > ~~~~~~~~~~~~~~~~ > Fruit>>mixWith: aFruit <:type: Fruit :> > ^ (Array with: self with: aFruit) <:type: Array E: Fruit :> > ~~~~~~~~~~~~~~~~ > Orange>>color > ^ (Color orange) <:type: Color :> > ~~~~~~~~~~~~~~~~ > (or even blocks) > [ :a1 <:type: Integer :> :a2 <:type: Integer :> | a1 + a2 ] > ~~~~~~~~~~~~~~~~ > > obviously something like this wouldn't even compile in Pharo (does Sqeak have different syntax for pragmas, or did the TypePlug change the syntax?) > This was based on a hacked compiler (using a smack grammar on top of a code generator based on RB Nodes similar to the one we have now in Opal). We changed the grammar to parse these kind of annotations. Marcus

Oct. 3, 2015

Re: [Pharo-users] NeoCSV and special handling for some columns

by Sven Van Caekenberghe

Yes, there are a couple of newer features that were added after the documentation was written. Keeping documentation up to date is also a PITA. > On 03 Oct 2015, at 08:54, stepharo <stepharo(a)free.fr> wrote: > > sven do you think that we should add this to the chapter? > > > Le 28/9/15 16:42, Sven Van Caekenberghe a Ã©crit : >>> On 28 Sep 2015, at 15:04, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>> >>> Imagine something like this: >>> >>> neoCSVReader := (NeoCSVReader on: stream). >>> neoCSVReader >>> separator: $,; >>> recordClass: PriceRecord; >>> addIgnoredField; "<name>" >>> addField: #securityUniqueId: ; "<ticker>" >>> addField: #date: converter: [ :string | Date readFrom: string readStream pattern: 'yyyymmdd' ]; "<date>" >>> addFloatField: #open: ; "<open>" >>> addFloatField: #high: ; "<high>" >>> addFloatField: #low: ; "<low>" >>> addFloatField: #close: ; "<close>" >>> addIntegerField: #volume: . "<vol>" >>> neoCSVReader skipHeader. >>> priceRecords := neoCSVReader upToEnd. >>> >>> >>> The #recordClass: is optional. If not, you can get an array of arrays instead. >>> You can add #addIgnoredField for all the ones you want to ignore, then add the #addNumber: etc for the number ones, etc. >> Correct. >> >>> To write a default empty value, I would use my own converter. Something like: >>> >>> addField: #stringcolumn: converter: [ :string | string isEmptyOrNil ifTrue: [ '' ] ]; >>> addField: #numbercolumn: converter: [ :string | string isEmptyOrNil ifTrue: [ 0 ] ifFalse: [ NeoNumberParser parse: string ] ]; >> Actually there is NeoCSVReader>>#emptyFieldValue: which you can use the configure the reader (but it counts for all fields). >> >>> Hope this helps. >>> >>> Cheers, >>> >>> >>> >>> On Mon, Sep 28, 2015 at 9:06 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: >>> Hi, >>> >>> I have two problems I could not solve: >>> >>> 1. I would like to read only some columns: I have a large file with >>> ~30 colums, but I am only interested on ~5 columns >>> (not that important, I could pre-process the file) but anyway it would be >>> nice to do it in smalltalk. >>> >>> 2. some columns will contain only strings (quoted values) and some only numbers, >>> but the field may be empty, is it possible to define the default "emptyValue" as an >>> - empty string for empty fields in the "string column" >>> - 0 for empty fields in the "number column"? >>> >>> >>> thanks >>> in advance >>> >>> nicolai >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >> >> > >

Oct. 3, 2015

Re: [Pharo-users] Accessors vs instance variables

by stepharo

Hi lyn I have the same experience than sven. Stef -Lyn > I think that with the current options in the tools (auto generation of accessors based on instance variables, checking references to instance variables, renaming either accessors or instance variables, syntax coloring) the difference between the two is becoming somewhat smaller. > > I used to consistently use accessors for the reasons you describe, but lately I find it more important to think as object oriented as possible, to maximise encapsulation and minimise the interface to the outside world. Now, I only add accessors if that really makes sense, the lack of accessors should then signal the private nature of the instance variable. > > Sven > > >

Oct. 3, 2015

Re: [Pharo-users] Analysis/Visualizations of DBs

by stepharo

Anne Etien and Olivier Auverlot (with the help of Guillaume Larcheveque) are parsing SQL and building representation in Moose about such objects. So contact anne anne.etien(a)inria.fr Le 2/10/15 14:34, Torsten Bergmann a Ã©crit : > Hi, > > we have many nice analysis and visualizations tools available (Moose, Roassal, ViDi, ...) > Often it is focused on development or code. Also we have refactoring tools. > > What would be cool would be to have some tool for doing this on (relational) databases and > included data: > > - visualize databases (tables, data clusters, number of columns, ...) > - analyze tables on satisfying some (external) business constraints > and consistency rules > - refactoring of databases (moving, migrating colums, ...) > - easy building reports/visualizations of included data (extract, query, filter, ...) > > What I think of is a tool where (after connecting to a possibly unknown database) you can easily > get/build an overview on the design, quality and data of the database (similar to what Moose, ViDi does > for code). > > Is there any research, projects, ... for data mining already in Pharo? I guess this could make > up a great toolset with Pharo as a base and make it more known because in the software business > relational databases play a big role. > > Any takers for the next Pharo success story? ;) > > Bye > T. > >

Oct. 3, 2015

Re: [Pharo-users] Spec LabelModel's #font: and other styles

by stepharo

I think that this part has been completely forgotten by spec. Normally the layout should take into account the size of the label and font and I do not see why we could not specify the color and other attributes we want to have but we did not work on this point. Now we will have to see that in the context of Brick skin. Stef Le 2/10/15 13:47, Peter UhnÃ¡k a Ã©crit : > Does it make sense to be able to specify font and similar at Spec-level? > > And not just font, also the size, color, or emphasis (which currently > only emphasis is supported). > > From one perspective it's handy, because I can change it at a whim, > however I wonder whether this shouldn't be responsibility of some > styler instead. > > Text as far as I know is capable of storing styled information. This > would enable to outsource the style information to someone else (e.g. > your stylesheet). However from practical perspective for the end user > it would be extra work as it would add an indirection step. > > For TextModel that would be clearly better (because you might want to > style different parts of text differently), however for LabelModel I'm > not so sure. > > Any opinions? > > Thanks, > Peter

Oct. 3, 2015

Re: [Pharo-users] Pillar for 30 gone the way of the dodo on the CI

by stepharo

So let us archive it but now my scripts are broken. Stef Le 1/10/15 10:10, Marcus Denker a Ã©crit : > >> On 01 Oct 2015, at 10:07, Marcus Denker <marcus.denker(a)inria.fr >> <mailto:marcus.denker@inria.fr>> wrote: >> >> Is CI an archive? >> > > What I mean: it seems to me not possible to keep all CI build alive > âforeverâ as a CI server build. > Shouldnât we separate âarchival of buildsâ from âactive ciâ? > > For Pharo itself we do that, as we do not have the manpower (we just > donât) to keep the CI alive for > stable and dev, yet every build ever is on files.pharo.org > <http://files.pharo.org> *forever*, archived. > > Marcus > >>> On 01 Oct 2015, at 10:05, Peter Uhnak <i.uhnak(a)gmail.com >>> <mailto:i.uhnak@gmail.com>> wrote: >>> >>> In Jenkins you specify configuration matrix (versions of pharo >>> versus type (development, stable, ...)).. So it will run development >>> for all versions, even pharo 30 (which is now permanently broken) >>> ------------------------------------------------------------------------ >>> From: Stephan Eggermont <mailto:stephan@stack.nl> >>> Sent: â10/â1/â2015 9:47 AM >>> To: pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org> >>> Subject: Re: [Pharo-users] Pillar for 30 gone the way of the dodo on >>> the CI >>> >>> On 01-10-15 09:41, Stephan Eggermont wrote: >>> > On 30-09-15 19:57, Ferlicot D. Cyril wrote: >>> > >>> >> We removed the Pillar job for Pharo 3 because we introduced an new >>> >> feature not backward compatible. >>> > >>> > Why is that a reason to remove the build? You have a configuration, >>> > don't you? >>> >>> I would suggest: move to a separate job that is run much less often >>> and doesn't keep so many old artifacts. That makes it easier to get old >>> stuff running again. >>> >>> Stephan >>> >>> >>> >> >

Oct. 3, 2015