January 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Spec: Binding widgets how to

by Offray Vladimir Luna CÃ¡rdenas

Hi, On 03/01/16 08:45, Nicolai Hess wrote: > > > There is any way to run a minimal GUI with a tree using your > example? I'm still missing a key concept on how to use spec and > binding between widgets. > > > what is missing ? this is a minimal gui with a tree component. Ohh, what is missing is not in the example, but in my understanding on how to use/start it. I would expect for something like "example openWithSpec" to start deconstructing it, but I'm still lost about it. I will be working on it today and tomorrow to see if I can come with better questions. Cheers, Offray

Jan. 3, 2016

Re: [Pharo-users] Working with a compressed Fuel file?

by Mariano Martinez Peck

I may have a hint. Which is the error upon materialization? A dnu on the stream? Which message? On Jan 3, 2016 4:19 PM, "Stephan Eggermont" <stephan(a)stack.nl> wrote: > I'm trying to work with a compressed Fuel file, without having to expand > everything at the same time. It looks like not all streams are created > equally. I seem to need a File instead of a FileReference: > > saveToFile > |zipStream fileRef| > fileRef := File named: (FileSystem disk workingDirectory / (self > fileName, '.zip')) pathString. > fileRef writeStreamDo: [ :s | > zipStream := GZipWriteStream on: s. > repository := nil. > FLSerializer serialize: self on: zipStream. > zipStream close]. > > > And materializing doesn't like this stream > > from: aFileName > |zipStream fileRef theNew| > fileRef := File named: aFileName. > fileRef readStreamDo: [ :s | > zipStream := GZipReadStream on: s. > theNew := (FLMaterializer new materializeFrom: zipStream) > root. > zipStream close]. > ^theNew > > How am I supposed to work with compressed Fuel files? > > Stephan > > >

Jan. 3, 2016

Working with a compressed Fuel file?

by Stephan Eggermont

I'm trying to work with a compressed Fuel file, without having to expand everything at the same time. It looks like not all streams are created equally. I seem to need a File instead of a FileReference: saveToFile |zipStream fileRef| fileRef := File named: (FileSystem disk workingDirectory / (self fileName, '.zip')) pathString. fileRef writeStreamDo: [ :s | zipStream := GZipWriteStream on: s. repository := nil. FLSerializer serialize: self on: zipStream. zipStream close]. And materializing doesn't like this stream from: aFileName |zipStream fileRef theNew| fileRef := File named: aFileName. fileRef readStreamDo: [ :s | zipStream := GZipReadStream on: s. theNew := (FLMaterializer new materializeFrom: zipStream) root. zipStream close]. ^theNew How am I supposed to work with compressed Fuel files? Stephan

Jan. 3, 2016

Re: [Pharo-users] [IMPORTANT] Starting migration to Spur VM

by EuanM

I'm happy to help with GUI design stuff. (I'm formally trained in HCI and in UI methods, e.g. STUDIO) Simply email me. -- View this message in context: http://forum.world.st/IMPORTANT-Starting-migration-to-Spur-VM-tp4866921p486… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Jan. 3, 2016

Re: [Pharo-users] Lawsuit Tracker app

by Dimitris Chloupis

For me the journey has been a bit diffirent. Secretely I was always look for a language that think diffirently and followed a more logical approach compared to converved approach of the vast majority of languages that follow C syntax. So I loved the Pharo diffirence. My real struggle was the lack of documentation, I was used to be spoon fed with other languages. My dismay is that many times here I was recommended to start reading pharo code. Suffice to say I was annoyed and frustrated because I was struggling to learn the basics of Pharo and foremost I was more annoyed that people insisted that code readability can replace documentation. Fast forward a couple years later and I have to admit they are kinda correct. Documentation cannot be replaced by code readability for begineers but as I get more and more experienced and familar with pharo and its culture and its libraries the more code I read the less I care about documentation. Unfortunately Pharo code readability is kinda a myth because there is a plenty of code inside pharo that is a huge pain to understand, Auto-completition is one example I struggle for hours and hour to understand and I failed. PharoLauncher is another. But I am getting better and I do believe one day I will be capable enough to read even unreadable pharo code. So I have to say to all those people that insisted that I should learn to read pharo code, thank you, this is indeed a very valuable skill to have. And I will even dare say it more important than documentation because because it does not explain only the what , but also the how and the why, which I think are very important. I completely agree with Esteban, learning a language is an investment. Someone tries Python for a month and finds it slow and goes to C++ , others invest their life implementing a high performance JIT VM like PyPy and create or python features in the language like string manipulation that outperforms C++. In the end its all about the hard work you do with your language and same applies to Pharo as well. Pharo can be used, every where, for anything at any time. Its an incredible useful tool , that inherits a lot of great designs from smalltalk, squeak and improves upon them. Something tells me I may be a pharo user for a long , long time. On Sun, Jan 3, 2016 at 7:52 PM Offray Vladimir Luna CÃ¡rdenas < offray(a)riseup.net> wrote: > Hi, > > On 03/01/16 08:08, SaÅ¡a JaniÅ¡ka wrote: > > > >> What I can tell you is that Pharo is **really** productive. > >> I suggest you to jump and get the feel for real. > >> Then do an analysis of pro and cons. > >> Doing that in the air is just doing it in the air. > > That's good advice...I'm a bit reluctant having feeling there are lot of > > things to learn before really starting, e.g. with some other languages > > it is very easy to provide call to C libs and explore things, while here > > it seems that learning curve is steeper...but I'll jump into it. > > > I was in a similar place half an a year ago: > > https://twitter.com/offrayLC/status/493979407011561473 > > This is what I'm doing today: > > https://offray.withknown.com/2016/matrix-sunburst-visualization-example > > So despite of the culture shock, it has been an excellent joyride! I > have never been able to express myself and feel as creative in any other > language/environment as with Pharo/Smalltalk. > > Is a different, but valuable travel to take. > > Cheers, > > Offray > > > >

Jan. 3, 2016

Re: [Pharo-users] Lawsuit Tracker app

by Offray Vladimir Luna CÃ¡rdenas

Hi, On 03/01/16 08:08, SaÅ¡a JaniÅ¡ka wrote: > >> What I can tell you is that Pharo is **really** productive. >> I suggest you to jump and get the feel for real. >> Then do an analysis of pro and cons. >> Doing that in the air is just doing it in the air. > That's good advice...I'm a bit reluctant having feeling there are lot of > things to learn before really starting, e.g. with some other languages > it is very easy to provide call to C libs and explore things, while here > it seems that learning curve is steeper...but I'll jump into it. I was in a similar place half an a year ago: https://twitter.com/offrayLC/status/493979407011561473 This is what I'm doing today: https://offray.withknown.com/2016/matrix-sunburst-visualization-example So despite of the culture shock, it has been an excellent joyride! I have never been able to express myself and feel as creative in any other language/environment as with Pharo/Smalltalk. Is a different, but valuable travel to take. Cheers, Offray

Jan. 3, 2016

Re: [Pharo-users] Spec: Binding widgets how to

by Nicolai Hess

2015-12-23 16:50 GMT+01:00 Offray Vladimir Luna CÃ¡rdenas <offray(a)riseup.net> : > Thanks Nicolai for your minimalist example. Only until now I have time to > test it (sorry), but I get some "MessageNotUnderstood: > SpecTreeNodeModel>>layoutFrame:" when I run this: > > ================= > | aClass subItems | > aClass := RTObject. > subItems := RTObject subclasses. > "create the node" > t := TreeNodeModel new > content: aClass name; > hasChildren: [ aClass subclasses notEmpty ]; > children: [ subItems ifNil:[subItems:=aClass subclasses collect: [ > :s | self buildNodeFor: s ] ]]; > yourself. > "listen on selection" > t whenSelectedChanged: [ :bool | bool ifTrue:[self field text: t content] > ]. > t openWithSpec > ================= > The children block codee only works as part of the class I defined with the method buildNodeFor: ( it calls "self buildNodeFor:") > > There is any way to run a minimal GUI with a tree using your example? I'm > still missing a key concept on how to use spec and binding between widgets. > what is missing ? this is a minimal gui with a tree component. > > Thanks, > > Offray > > > On 29/11/15 13:51, Nicolai Hess wrote: > > > > 2015-11-26 19:36 GMT+01:00 Offray Vladimir Luna CÃ¡rdenas < > <offray(a)riseup.net>offray(a)riseup.net>: > >> Hi, >> >> I had tried that before and didn't work. Passing information between >> widgets and back in this spec interface seems my stop point now... If >> someone could help me with some kind of minimalist example that uses >> treeModel, that would be greatly appreciated. >> > > Find attached a minimal example. (I use Morph and its subclasses for > generating some tree data, these are just names, renaming a node does not > rename the class :)) > > You can listen on tree node selection by registering with > #whenSelectedChanged, on the TreeNode(!) > > "create the node" > t := TreeNodeModel new > content: aClass name; > hasChildren: [ aClass subclasses notEmpty ]; > children: [ subItems ifNil:[subItems:=aClass subclasses collect: [ > :s | self buildNodeFor: s ] ]]; > yourself. > > "listen on selection" > t whenSelectedChanged: [ :bool | bool ifTrue:[self field text: t content] > ]. > > this will change the text field content with the content of the node (the > default label). > > Changing the label node *Morph* on accepting the text field text is > somehow impossible or difficult. > I would have expected that Spec would create a MorphicTreeNodeAdapter that > represents some Morph, for which the adapter would update/change the state, > if you change > the TreeNodeModel content. > Instead, it creates some strange SpecTreeNodeModel. And the only way to > update the NodeLabel and make this change visible is to > rebuild the whole tree: > > tree roots: tree roots. > > Yes, I did not find another way. > > Luckily MorphTreeMorph is smart enough to remember the selection and path > expansion state, so this works quite well. > > > >> >> Cheers, >> >> Offray >> >> >> On 26/11/15 12:47, webwarrior wrote: >> >>> Try #whenHighlightedItemChanged: method. >>> >>> I remember that distinction between selection/highlight is not very >>> clear in >>> TreeModel. >>> >>> >>> >>> -- >>> View this message in context: >>> <http://forum.world.st/Spec-Binding-widgets-how-to-tp4863742p4863757.html> >>> http://forum.world.st/Spec-Binding-widgets-how-to-tp4863742p4863757.html >>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>> >>> >>> >> >> > >

Jan. 3, 2016

Re: [Pharo-users] Lawsuit Tracker app

by SaÅ¡a JaniÅ¡ka

On Ned, 2016-01-03 at 11:31 +0100, stepharo wrote: > Yes Synectique is building a lot of interfce with Glamour. > Yes Magritte is relevant now the Morphic binding may not work. Thank you. > What I can tell you is that Pharo is **really** productive. > I suggest you to jump and get the feel for real. > Then do an analysis of pro and cons. > Doing that in the air is just doing it in the air. That's good advice...I'm a bit reluctant having feeling there are lot of things to learn before really starting, e.g. with some other languages it is very easy to provide call to C libs and explore things, while here it seems that learning curve is steeper...but I'll jump into it. Sincerely, Gour -- A person is considered still further advanced when he regards honest well-wishers, affectionate benefactors, the neutral, mediators, the envious, friends and enemies, the pious and the sinners all with an equal mind.

Jan. 3, 2016

Re: [Pharo-users] Lawsuit Tracker app

by Esteban Lorenzano

> On 03 Jan 2016, at 10:11, John Pfersich <jpfersich(a)gmail.com> wrote: > > > > Sent from my iPad > >> On Jan 2, 2016, at 23:57, SaÅ¡a JaniÅ¡ka <gour(a)atmarama.com> wrote: >> >>> On Sub, 2016-01-02 at 23:27 +0000, Dimitris Chloupis wrote: >>> >>> there is an an SQlite wrapper for pharo >> >> I know about it. >> >> However it would be nice to have some categorized catalog of the >> packages available for Pharo? >> > > +1 > I find that I just browse the Configuration Browser to see what's out there and then google the name to see if I can find any documentation. you have it: http://catalog.pharo.org <http://catalog.pharo.org/> configuration browser was not good enough so we replaced it in Pharo 5 (packages can be used in older versions, and they are listed in the catalog web page). but againâ¦ no tool can survive if people does not contribute. Esteban > > And it would be nice to have a wiki like Squeak's. > >>> the screenshot you shared as Tudor said can be accomplished via >>> Roassal and Morphic. >> >> Now, I'm really a bit puzzled about Roassal' capabilities. :-) >> >>> Personally I find the whole performance question kinda irrelevant >>> because if you really want to squeeze the most performance code those >>> parts in C and call them from Pharo via its FFI. Not even Julia will >>> able to outperform that since itself relies on C code for performance >>> and its quite restrictive how you use its dynamic types to achieve >>> high performance. >> >> Well, the point is that e.g. I know people who tried to do similar apps >> in Python and it was too slow, they abandoned it and went to C++. >> >> That's the reason why I was primarily exploring statically-compiled >> languages. Julia *might* be interesting since it is higher-level >> language with fantastic, close to C performance when one helps compiler >> by annotating data types. >> >> In short, I want to avoid fiddling with low-level languages, otherwise >> it would be simple to just use C/GTK or C++/Qt. (Java could probably >> also do the job, but I simply do not like it.) >> >> For the most critical part of the application, I anyway plan to use 3rd >> party C lib which does calculate planetary ephemeris, but for the custom >> libs using it, I want to use higher-level and type-safer language. >> >>> In any case there are always 3 rules, profile, profile and profile. >>> When it comes to performance assume nothing. In the vast majority of >>> cases Pharo JIT VM should be more than enough. >> >> Let me see... >> >>> And if all you want to do is a business app I dont even know why you >>> worry about performance. Business apps they are very low demand on >>> performance. >> >> When I say 'business' app, it is most in the sense of typical 'desktop >> outlook', while the app itself is falling more into 'science' app, but >> it depends how one sees astronomy/astrology. :-) >> >>> Pharo libraries dont get irrelevant because the language is so simple >>> it barely changes and the changes usually dont brake compatibility. >> >> Pharo's simplicity of the language is huge 'pro'. ;) >> >>> Pharo can do REPL via the playground, the whole deal is that is a lot >>> more than that. >> >> Right, it's just that Julia provides more 'traditional' dev work-flow, >> while with Pharo one has to unwrap one's head a bit. :-) >> >>> GUI wise you can do some pretty awesome stuff with morphic. >> >> That I still have to learn... >> >> >> Sincerely, >> Gour >> >> -- >> A person is said to be elevated in yoga when, having renounced >> all material desires, he neither acts for sense gratification >> nor engages in fruitive activities. >> >> >> >> >> >

Jan. 3, 2016

Re: [Pharo-users] Lawsuit Tracker app

by Esteban Lorenzano

> On 03 Jan 2016, at 08:57, SaÅ¡a JaniÅ¡ka <gour(a)atmarama.com> wrote: > > On Sub, 2016-01-02 at 23:27 +0000, Dimitris Chloupis wrote: > >> there is an an SQlite wrapper for pharo > > I know about it. > > However it would be nice to have some categorized catalog of the > packages available for Pharo? > > >> the screenshot you shared as Tudor said can be accomplished via >> Roassal and Morphic. > > Now, I'm really a bit puzzled about Roassal' capabilities. :-) > >> Personally I find the whole performance question kinda irrelevant >> because if you really want to squeeze the most performance code those >> parts in C and call them from Pharo via its FFI. Not even Julia will >> able to outperform that since itself relies on C code for performance >> and its quite restrictive how you use its dynamic types to achieve >> high performance. > > Well, the point is that e.g. I know people who tried to do similar apps > in Python and it was too slow, they abandoned it and went to C++. for me, that just means they are bad python programmers (and most probably they will not do a good job on C++ either)â¦ this thing about performance is a really stablished prejudiceâ¦ but most of the time not true. IMO what you need to do is to build your app and optimise *if needed*, by interfacing with low level/more performant libraries. Esteban > > That's the reason why I was primarily exploring statically-compiled > languages. Julia *might* be interesting since it is higher-level > language with fantastic, close to C performance when one helps compiler > by annotating data types. > > In short, I want to avoid fiddling with low-level languages, otherwise > it would be simple to just use C/GTK or C++/Qt. (Java could probably > also do the job, but I simply do not like it.) > > For the most critical part of the application, I anyway plan to use 3rd > party C lib which does calculate planetary ephemeris, but for the custom > libs using it, I want to use higher-level and type-safer language. > >> In any case there are always 3 rules, profile, profile and profile. >> When it comes to performance assume nothing. In the vast majority of >> cases Pharo JIT VM should be more than enough. > > Let me see... > >> And if all you want to do is a business app I dont even know why you >> worry about performance. Business apps they are very low demand on >> performance. > > When I say 'business' app, it is most in the sense of typical 'desktop > outlook', while the app itself is falling more into 'science' app, but > it depends how one sees astronomy/astrology. :-) > >> Pharo libraries dont get irrelevant because the language is so simple >> it barely changes and the changes usually dont brake compatibility. > > Pharo's simplicity of the language is huge 'pro'. ;) > >> Pharo can do REPL via the playground, the whole deal is that is a lot >> more than that. > > Right, it's just that Julia provides more 'traditional' dev work-flow, > while with Pharo one has to unwrap one's head a bit. :-) > >> GUI wise you can do some pretty awesome stuff with morphic. > > That I still have to learn... > > > Sincerely, > Gour > > -- > A person is said to be elevated in yoga when, having renounced > all material desires, he neither acts for sense gratification > nor engages in fruitive activities. > > > > >

Jan. 3, 2016