February 2015 - Pharo-users

Re: [Pharo-users] What UI direction now (or in the near future)?

by stepharo

Do not ask alain extra work. Read Bloc code. Stef > Pharo Smalltalk Users mailing list wrote >> now, design decisions are to be made regarding the widgets layer. > I assume you've studied the original Self Morphic, which seemed very simple > and elegant in my brief experiments with it. One of the key principles was > uniformity e.g. the World, Hand, etc could all be regular objects, like any > other Morph. Our implementation creates special cases which are barriers to > understanding and experimentation e.g. it's very difficult to create and > customize a World within a Worldâ¦ > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/What-UI-direction-now-or-in-the-near-future-tp4807447… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Feb. 26, 2015

Re: [Pharo-users] What UI direction now (or in the near future)?

by stepharo

Do not confuse things. Athens is a CANVAS it has ***nothing*** to do with events. Events are managed by the UI layer not the drawing layer. Athens is about drawing. > Morphic has been around for over a decade. Probably it will stay for a while. > Athens is quite stable. However it is not made to do UI. It does not do much for event handling. Roassal does the drawing with Athens and the event management with Morphic. > > Cheers, > Alexandre > >> On Feb 25, 2015, at 12:02 AM, Petr Fischer <petr.fischer(a)me.com> wrote: >> >> Hello! >> >> Suppose, that I need to write simple UI app + write my own UI list component (some special behaviour, canât use default list UI component from Pharo) + I need perfect keyboard support (shortcuts, tab navigation + navigation by cursor keys in some windows), which also means, that I need perfect UI component âfocusâ supportâ¦ >> >> Another priority: I do not want to learn things (in exhaustive detail) that expire in 2 years. >> >> Current status: I like Smalltalk (Pharo!), know basics of Morphic and I noticed some future as Athens and Bloc. I am trying to get out from âclosedâ app development and Apple âclosedâ technologies as ObjC/Swift/Cocoa and want to be little more productive and platform independent. Simple, snappy, attractive and smooth UI is the key for me/users. >> >> And nowâ¦ which direction: >> >> 1) old Morphic (simple powerful work with old Morphs etc.) >> >> 2) Morphic + Athens drawing (maybe I donât understand the connection) >> >> 3) Bloc >> >> Sub-questions: >> >> A) Is Bloc (complete Morphic rewrite, sigh) âone man showâ? What about future, support, long-term issues? Look at Marina CMS framework, even used for Pharo website, but not maintained now... >> >> B) Is Bloc prepared with Retina displays in mind (perfect smooth fonts and graphics, scaling, more detailed images for retina etc.)? >> >> C) Is current keyboard + UI component focus support perfect or pain in... >> >> Isnât a âbad timeâ for this decision (Pharo) now? >> >> Thanks very much for any brief hint, Petr Fischer >> >> >>

Feb. 26, 2015

Re: [Pharo-users] [clubSmalltalk] Re: [ANN] StNER: Interface to Stanford Named Entity Recognizer

by Alexandre Bergel

Oh! Interesting!!! Cheers, Alexandre > On Feb 26, 2015, at 2:06 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > I have to finish the PhyloclassTalk paper. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 26, 2015

Re: [Pharo-users] BaselineOf vs ConfigurationOf

by Dale Henrichs

On 2/26/15 4:41 AM, Ben Coman wrote: > Just a random query (especially since I haven't played with BaselineOf > and I might misunderstand something)... > should #baseline: be moved out of the ConfigurationOf class so that we > consistently have a BaselineOf class in both cases: git & monticello. Haha, you are misunderstanding ... the two classes are separate because they are independent classes. One should use one or the other for managing a project. If you have a git-based project then I recommend that you use a BaselineOf to manage the packages and dependent projects. If you are using a Monticello repository (mcz files) then you must use a ConfigurationOf ... > > That is, the ConfigurationOfXxx.mcz package will contain two classes: > ConfigurationOfXxx and BaselineOfXxx. > This will not work as you expect:) Dale

Feb. 26, 2015

Re: [Pharo-users] BaselineOf vs ConfigurationOf

by Dale Henrichs

Martin, In my work I am moving entirely away from ConfigurationOf ... ConfigurationOf was invented because Monticello lacks the ability to reason about multi-file versions so virtually all of the meta data in a ConfigurationOf is making up for this lack. Of course, the ConfigurationOf only partially fills the gap ... Git handles multi-file versions as well as branches so all of the extra meta data in the ConfigurationOf is totally unnecessary once you start using git. The BaselineOf manages the meta data that is still required in the presence of git: - package load order - project dependencies One can use tags directly in a project reference so configurations can be completely eliminated. Dale On 2/25/15 7:05 AM, Martin BÃ¤hr wrote: > Excerpts from Thierry Goubier's message of 2015-02-25 15:43:39 +0100: >> BaselineOf is the same as a #baseline: in a ConfigurationOf. It describes >> dependencies, packages and groups for a project, without versions. On >> loading, a BaselineOf will behave as a #development version in a >> ConfigurationOf which is to load the latest versions of the packages listed >> (and whatever dependencies listed). > sounds to me like one should use branches for baseline (since they update) > and tags for versions in configuration (since they stay on the same commit) > >> Repositories urls which support branches and tags are github:// and >> bitbucket:// urls; which support branches (and not tags) are gitfiletree:// >> urls. > oh, any particular reason, or just work in progress? > > greetings, martin. >

Feb. 26, 2015

Re: [Pharo-users] BaselineOf vs ConfigurationOf

by Thierry Goubier

2015-02-26 13:41 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > Just a random query (especially since I haven't played with BaselineOf and > I might misunderstand something)... > should #baseline: be moved out of the ConfigurationOf class so that we > consistently have a BaselineOf class in both cases: git & monticello. > > There is some elegance in having the same scheme, yes. > > That is, the ConfigurationOfXxx.mcz package will contain two classes: > ConfigurationOfXxx and BaselineOfXxx. > Hum, I'm not sure it will work. I'm under the feeling that Metacello expects the baseline to be in a package of the same name (BaselineOf) and that it wouldn't work. Dale? Thierry > > cheers -ben > > On Wed, Feb 25, 2015 at 11:05 PM, Martin BÃ¤hr < > mbaehr(a)email.archlab.tuwien.ac.at> wrote: > >> Excerpts from Thierry Goubier's message of 2015-02-25 15:43:39 +0100: >> > BaselineOf is the same as a #baseline: in a ConfigurationOf. It >> describes >> > dependencies, packages and groups for a project, without versions. On >> > loading, a BaselineOf will behave as a #development version in a >> > ConfigurationOf which is to load the latest versions of the packages >> listed >> > (and whatever dependencies listed). >> >> sounds to me like one should use branches for baseline (since they update) >> and tags for versions in configuration (since they stay on the same >> commit) >> >> > Repositories urls which support branches and tags are github:// and >> > bitbucket:// urls; which support branches (and not tags) are >> gitfiletree:// >> > urls. >> >> oh, any particular reason, or just work in progress? >> >> greetings, martin. >> >> -- >> eKita - the online platform for your entire academic >> life >> -- >> chief engineer >> eKita.co >> pike programmer pike.lysator.liu.se caudium.net >> societyserver.org >> secretary >> beijinglug.org >> mentor >> fossasia.org >> foresight developer foresightlinux.org >> realss.com >> unix sysadmin >> Martin BÃ¤hr working in china >> http://societyserver.org/mbaehr/ >> >> >

Feb. 26, 2015

Re: [Pharo-users] BaselineOf vs ConfigurationOf

by Ben Coman

Just a random query (especially since I haven't played with BaselineOf and I might misunderstand something)... should #baseline: be moved out of the ConfigurationOf class so that we consistently have a BaselineOf class in both cases: git & monticello. That is, the ConfigurationOfXxx.mcz package will contain two classes: ConfigurationOfXxx and BaselineOfXxx. cheers -ben On Wed, Feb 25, 2015 at 11:05 PM, Martin BÃ¤hr < mbaehr(a)email.archlab.tuwien.ac.at> wrote: > Excerpts from Thierry Goubier's message of 2015-02-25 15:43:39 +0100: > > BaselineOf is the same as a #baseline: in a ConfigurationOf. It describes > > dependencies, packages and groups for a project, without versions. On > > loading, a BaselineOf will behave as a #development version in a > > ConfigurationOf which is to load the latest versions of the packages > listed > > (and whatever dependencies listed). > > sounds to me like one should use branches for baseline (since they update) > and tags for versions in configuration (since they stay on the same commit) > > > Repositories urls which support branches and tags are github:// and > > bitbucket:// urls; which support branches (and not tags) are > gitfiletree:// > > urls. > > oh, any particular reason, or just work in progress? > > greetings, martin. > > -- > eKita - the online platform for your entire academic > life > -- > chief engineer > eKita.co > pike programmer pike.lysator.liu.se caudium.net > societyserver.org > secretary > beijinglug.org > mentor > fossasia.org > foresight developer foresightlinux.org > realss.com > unix sysadmin > Martin BÃ¤hr working in china > http://societyserver.org/mbaehr/ > >

Feb. 26, 2015

Pharo-Launcher does not launch image in Ubuntu

by nacho

Hi, pharo-launcher starts perfectly, I can even download i.e. the latest Pharo 4 beta, but when trying to launch that image I receive the following error 200 times or more until pharo closes *** stack smashing detected ***: /usr/lib/pharo-vm/pharo-vm terminated output file stack is full. I did some chowns to /usr/lib/pharo-vm /usr/share/pharo-vm and /usr/share/pharo-launcher Even run pharo as root But nothing seems to work I loaded ppa:pharo/unstable I'm using Netrunner 15 x86_64 (which is based in Ubuntu Utopic) Thanks in advance for any help. Nacho ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/Pharo-Launcher-does-not-launch-image-in-Ubuntu-tp4807… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Feb. 26, 2015

Re: [Pharo-users] Git (gitfiletree) on Pharo vs Windows

by Thierry Goubier

2015-02-26 11:06 GMT+01:00 Jan B. <bliznjan(a)fit.cvut.cz>: > Hi > > This time, when I add gitfiletree repository via monticello, it loads all > packages and classes. > However, it does not load any methods. Even if I use "Browse" in repository > window, it displays class definition, including variables and category > correctly, but still no methods. Normal filetree shows and loads these > methods. > Strange. Really strange. Why? Because what GitFileTree does for loading is request an archive from git (i.e. a zip file) and load all definitions from it. If the zip was corrupted or not available in a way or another, it would not load anything... or could it be a case sensitivity problem on method names? > > And another thing is that if I try to add and load gitfiletree repository > via following command, not GUI, I get an Error: filetree:// repository > 'C:\Users\User\Pharo\ourproject\repository\' does not exist > > command was: > > Metacello new > baseline: 'OurProject'; > repository: 'gitfiletree:///C:\Users\User\Pharo\ourproject\repository'; > load. > > when I delete that 'git' characters and leave just repository: > 'filetree:///C:\Users (etc.), it loads fine, too, but it may be my mistake. > I don't know. It's hard to do this remote debugging of a kind :( Everything seems to be different in unexpected places. Thierry > > Jan > > > Thierry Goubier wrote > > Hi Jan, > > > > I pushed a new version (development) of GitFileTree using ProcessWrapper > > on Windows (version 82 on Smalltalkhub). > > > > You need to get ProcessWrapper loaded first, of course, from the > > Configuration browser in Pharo 3. > > > > If you want to try? > > > > Thierry > > > > > > -- > View this message in context: > http://forum.world.st/Git-gitfiletree-on-Pharo-vs-Windows-tp4806791p4807789… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Feb. 26, 2015

Re: [Pharo-users] [ANN] StNER: Interface to Stanford Named Entity Recognizer

by stepharo

https://pharoweekly.wordpress.com/2015/02/26/pharo-interface-to-the-stanfor… :) Great job! Stef Le 25/2/15 22:48, HernÃ¡n Morales Durand a Ã©crit : > Hello, > > I am announcing the release of StNER. StNER provides a Pharo Smalltalk > interface to the Stanford Named Entity Recognizer (NER). > (http://nlp.stanford.edu/software/CRF-NER.shtml) > > Installation and usage details are described in the following post: > > http://80738163270632.blogspot.com.ar/2015/02/stner-interface-to-stanford-n… > > Cheers, > > HernÃ¡n > > PS: Only tested in Windows 8.1 >

Feb. 26, 2015