- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Bloc: Problems Running

by Sean P. DeNigris

Sean P. DeNigris wrote > What would it take to add the various setups to the CI matrix? This > complexity will be a high barrier to feedback... In fact, if the current artifacts are unusable, it would probably be better to disable them, like Esteban did for the 5.0 VM job... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Bloc-Problems-Running-tp4924930p4925230.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 30, 2016

Re: [Pharo-dev] Bloc: Problems Running

by Nicolas Passerini

2016-11-29 13:08 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > And my problem was related to feature/issue of Iceberg to require github > keys. This is interesting for my, which operation did demand for your github keys? I mean, were keys need for that operation or did Iceberg ask you for keys before they are needed?

Nov. 29, 2016

Re: [Pharo-dev] How to report website text bugs?

by stepharo

On Tue, 29 Nov 2016 00:57:36 +0100, Tim Mackinnon <tim(a)testit.works> wrote: > Hi Guys - how is the best way to report website and text bugs? > > As I know the English is not always a first language (and you guys are > busy writing code anyway) - its up to us native English speakers >to > chip in where we can. Thank you for this take :) > I was pleased to get the notice that on OSX Sierra I need to do > something extra to get Pharo to work, however the text could be slightly > >corrected eg. (Bolded words changed) > > Are you using macOS Sierra? > Due to changes in security policies of macOS, you will need to put the > VM in the /Applications folder. > We are working to fix this temporary inconvenience. > > > Also - the Hello world command line example on the front page doesnât > work on a standard Terminal on a Mac (you get an error: > > $ ./pharo Pharo.image eval "Stdio stdout << 'Hello,World!'" > -bash: !'": event not found > >> The culprit is of course the â!â Character so a better example might be: > >>> $ ./pharo Pharo.image eval "Stdio stdout << 'Hello World'" > Hello WorldStdioStream: 'stdout' > > Although, in this case, is it expected that the return string is merged > with some other output text >(e.g. the StdioStream:â¦.?). I think its an > impressive example, but it just doesnât quite look right? > > > Tim -- Using Opera's mail client: http://www.opera.com/mail/

Nov. 29, 2016

Re: [Pharo-dev] two question about fasttable

by stepharo

On Tue, 29 Nov 2016 10:46:09 +0100, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >> Called by the table view to return the data object associated with the >> specified row and column. > https://developer.apple.com/reference/appkit/nstableviewdatasource/1533674-… If dataSource does not return view then you are right for the name. Now in Pharo the name is wrong and may be the design too :) > > Cheers, > Alex > > On 29 November 2016 at 10:44, Aliaksei Syrel <alex.syrel(a)gmail.com> > wrote: >> >>>> On 29 November 2016 at 10:39, Esteban Lorenzano <estebanlm(a)gmail.com> >>>> wrote: >>> not true.it returns an NSView. >> >> Could you name a method (send a link to a documentation) that is >> implemented by DataSource and returns an NSView? >> >> According to documentation NSView for an item at row/column index is >> created and returned by NSTableView: >> https://developer.apple.com/reference/appkit/nstableview/1528831-view >> >> I didn't find any NSView related method in DataSource. Am I looking in >> a wrong place? >> >> Cheers, >> Alex > -- Using Opera's mail client: http://www.opera.com/mail/

Nov. 29, 2016

Re: [Pharo-dev] two question about fasttable

by stepharo

On Tue, 29 Nov 2016 09:58:41 +0100, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > "DataSource" is responsible for providing visual elements that represent > items in a data set. who said that. I could say exactly: DataSource is responsible to cut data so that they are delivered by row or columns. > > I don't see how word "Store" fits here, because DataSource does not > store anything. Store in the sense of serving something. > DataSource is also not the best name since it is not a data source > itself. Clearly not > An object that is now called DataSource, basically just knows a single > function that from mathematical point of view can be defined as >follows: > f: Object -> Morph . You see, it is a mapping, not a souse or store. > > Cheers, > Alex > > On 29 November 2016 at 09:44, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: >> >>>> 2016-11-29 9:35 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>>>> yes, something like TableCellSource or TableCellProvider is more >>>>>>> intention revealing. >>> >>> No, because is not *just* a cell provider.TableDataSource, TableStore, >>> TableProvider, yes. >>> >>> I kind of like âTableStoreâ. >> >> And if we have TableMorph then this guy should be TableMorphStore IMO. > -- Using Opera's mail client: http://www.opera.com/mail/

Nov. 29, 2016

Re: [Pharo-dev] two question about fasttable

by stepharo

> > No, because is not *just* a cell provider.TableDataSource, TableStore, > TableProvider, yes. > > I kind of like âTableStoreâ.Also we have other stores in image: > FileSystem storesâ¦ which conceptually do more or less the sameâ¦ so > better to unify concepts/>namesâ¦ what do you think? TableMorphStore? Because I was really shocked to see that it returned Morph. > > Esteban > >> >> Christophe > -- Using Opera's mail client: http://www.opera.com/mail/

Nov. 29, 2016

Re: [Pharo-dev] two question about fasttable

by stepharo

>>> >>> >>>>>>>> - Then I miss an important design point. Why datasource returns >>>>>>>> Morph? >>>> I do not get get why a data source should return UI element. To me it >>>> violates layers. >>> >>> no, because thatâs its purpose: to provide the table with the cell >>> elements (which are by definition Morphsâ¦ any kind of >>>morphs).a >>> TableDataSource is not a spec, is the provider of cells. >>> >>> >> >> so maybe TableCellSource / TableCellProvider ? > > Iâm not against changing its name, in general the family of names are > âDataSourceâ, âStoreâ, etc. so I imagine that âProviderâ fits (even if I > >tend to hate names style âManagerâ, âFactoryâ, âProviderâ, because > there are too genericâ¦ sometimes is that what you have :P) > But is not just a âcell providerâ, it does something more, is a general > model of the TableMorph: it provides cells, headers and interaction > >capabilities (like drag&drop)â¦ so it is more like a "table data > providerâ, TableDataSource, TableStore, TableProvider are then better > >names, IMOâ¦ Please please please. So I was always confused. > > this changes will impact Pharo 7â¦ is very good that we can have a > discussion like this now, that we have the time to reach a consensus >:) > > Esteban > >> >> cheers -ben > -- Using Opera's mail client: http://www.opera.com/mail/

Nov. 29, 2016

Re: [Pharo-dev] two question about fasttable

by stepharo

On Mon, 28 Nov 2016 22:29:08 +0100, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, >> On 28 Nov 2016, at 21:32, stepharo <stepharo(a)free.fr> wrote: >> >> Hi >> >> - Could we rename FastTable into Table? > > not for Pharo 6 but Pharo 7 yesâ¦ in fact, I think it should be called > TableMorph. > (Also we need to refactor a lot, to eliminate the FT prefix, etc.) > >> >> - Then I miss an important design point. Why datasource returns Morph? >> I do not get get why a data source should return UI element. To me it >> violates layers. > > no, because thatâs its purpose: to provide the table with the cell > elements (which are by definition Morphsâ¦ any kind of morphs).a > TableDataSource is not a spec, is the provider of cells. What a ugly name then... Why this is not a CellMorphFactory or something like that. > > I got inspired for Cocoa NSTableView design (and NSTableViewDataSource), > and thatâs what it does.See for example here: > https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/…>TablesProgrammatically/PopulatingView-TablesProgrammatically.html > This function: >- (NSView *)tableView:(NSTableView *)tableView > viewForTableColumn:(NSTableColumn *)tableColumn > row:(NSInteger)row > > is the equivalent of our FTDataSource>>cellColumn:row: > > Esteban > >> >> Stef >> >> >> >> --Using Opera's mail client: http://www.opera.com/mail/ >> > -- Using Opera's mail client: http://www.opera.com/mail/

Nov. 29, 2016

Re: [Pharo-dev] two question about fasttable

by stepharo

Ok so I never understand it that way. What a bad name. Stef > >> On 28 Nov 2016, at 22:25, Henrik Nergaard <henrik.nergaard(a)uia.no> >> wrote: >> >> The datasource is a wrapper/binding between the real object and the >> view (table/list) and provides the necessary stuff for >>display and >> interaction between them. Returning custom UI elements (cells and rows) >> from the datasource is part of what >>makes it possible to reuse the >> same table/container morph for lists/tables/trees. > > this ^ :) > > Esteban > -- Using Opera's mail client: http://www.opera.com/mail/

Nov. 29, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60309 Home: https://github.com/pharo-project/pharo-core

Nov. 29, 2016