January 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Gofer issue

by Dale Henrichs

On 01/21/2011 08:11 AM, Miguel CobÃ¡ wrote: > El vie, 21-01-2011 a las 11:05 +0100, Igor Stasenko escribiÃ³: > >> Okay, i found the solution. Use Installer ! >> >> Installer monticello http: 'http://www.squeaksource.com'; >> project: 'VMMaker'; >> install: 'CMakeVMMaker' >> >> >> works well for me and loads correct *latest* version. > > That isn't a solution and open again a gratuitous discussion about gofer > vs installer. > > The point is, in a distributed SCM system, like Monticello is, there > isn't a latest version. At least not by the traditional (suversion for > example) way of knowing the monotone numeric integer version number. As > Lukas said, the only way to know something is latest is to compare > timestamps, but not version numbers or commits id. They aren't not > intended to be ordered respect to time. > > Cheers > Miguel, A timestamp isn't sufficient in the presence of branching. How do other SCMs identify branches? Dale

Jan. 21, 2011

Re: [Pharo-project] Issue 3570 in pharo: EdgeGripMorph DNU when resizing

by pharo＠googlecode.com

Comment #1 on issue 3570 by tudor.gi...(a)gmail.com: EdgeGripMorph DNU when resizing http://code.google.com/p/pharo/issues/detail?id=3570 Name: SLICE-Issue-3570-EdgeGripMorph-DNU-when-resizing-TudorGirba.1 Author: TudorGirba Time: 21 January 2011, 9:43:32 pm UUID: b156c996-6938-4819-b242-9ca0316a5e6e Ancestors: Dependencies: Polymorph-Widgets-TudorGirba.373, Morphic-TudorGirba.820 Fix from Gary

Jan. 21, 2011

[Pharo-project] Issue 3570 in pharo: EdgeGripMorph DNU when resizing

by pharo＠googlecode.com

Status: Accepted Owner: tudor.gi...(a)gmail.com Labels: Milestone-1.2 Type-Patch Importance-Low New issue 3570 by tudor.gi...(a)gmail.com: EdgeGripMorph DNU when resizing http://code.google.com/p/pharo/issues/detail?id=3570 From Andreas Wacknitz: 1. downloaded 12303: https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.2/67/artifa… 2. filed in the attached CS 3. executed | m leftMorph scroll | m := PanelMorph new. m hResizing: #shrinkWrap; vResizing: #spaceFill; changeTableLayout; listDirection: #leftToRight. m addMorphBack: (leftMorph := Morph new color: Color red; minimumExtent: 150@10; extent: 150@10; hResizing: #rigid; "shown for clarity, is the default" vResizing: #spaceFill). m addMorphBack: (EdgeGripMorph new width: ProportionalSplitterMorph splitterWidth; hResizing: #rigid; "not the default this time, vResizing is also #spaceFill by default" target: leftMorph). m addMorphBack: (Morph new color: Color green; minWidth: 100; hResizing: #shrinkWrap; vResizing: #spaceFill). scroll := GeneralScrollPane new changeScrollerTableLayout; scrollTarget: m. scroll openInWindow. 4. When I execute the code in a Workspace a little dialog will open. It has a horizontal scroll bar that I can use. As soon as I move the splitter I will get the aforementioned DNU. I am on Mac OS 10.6.6.

Jan. 21, 2011

Re: [Pharo-project] Instruments for headless images

by Igor Stasenko

On 21 January 2011 21:15, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Fri, Jan 21, 2011 at 11:44 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> Eliot >> >> does it mean that we could run headless and that if specified on the >> command line we could for example get a debugger open on bugs? Because I >> would love that for coral. > > Exactly. Â In fact I think one mode is that one can get the system to > snapshot when the error happens, one can then send the snapshot to a > developer, and the snapshot comes up headful with the debugger. > that what i actually meant by 'log error, save & quit ' option >> >> Stef > > -- Best regards, Igor Stasenko AKA sig.

Jan. 21, 2011

Re: [Pharo-project] New chapter on OpenGL in Pharo

by Luc Fabresse

Hi Javier, Very cool indeed! I will try to read it soon. #Luc 2011/1/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Jan 21, 2011, at 6:14 AM, Javier PimÃ¡s wrote: > > > Hi! I just gathered many of my previous experiences trying to use opengl > and uploaded it to the pharo book. It would be nice if someone could check > the info, try to add more and mainly test the tips to see if they are > working. > > Thanks!!! > Documenting is important so that we all learn. > > > With FFI OpenGL I'm getting an error while compiling a test method in > Pharo 1.2 and some problems with underscore assignments and deprecations, we > should fix them but I don't think I have access to that repo. Also, loading > it involves many steps, having a ConfigurationOfFFIOpenGL would be awsome. > > > > Please add anything you consider useful. > > > > Regards, > > Javier. > > > > -- > > Javier PimÃ¡s > > Ciudad de Buenos Aires > > >

Jan. 21, 2011

Re: [Pharo-project] Instruments for headless images

by Eliot Miranda

On Fri, Jan 21, 2011 at 11:44 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Eliot > > does it mean that we could run headless and that if specified on the > command line we could for example get a debugger open on bugs? Because I > would love that for coral. > Exactly. In fact I think one mode is that one can get the system to snapshot when the error happens, one can then send the snapshot to a developer, and the snapshot comes up headful with the debugger. > > Stef >

Jan. 21, 2011

Re: [Pharo-project] Gofer issue

by Miguel CobÃ¡

El vie, 21-01-2011 a las 21:00 +0100, Igor Stasenko escribiÃ³: > So lets do the same and get rid of numbers. > So, name will be > > PackageName-SHA1.mcz > > everything else, like author and commit date is in package I am for this change, but as I pointed before, it would break things, or more surely, it will be the turning point between Squeak/Pharo, as the same tool couldn't be used to manage the same code. The code will need to be packaged twice, once for squeak, once for pharo. Unless that Squeak also adopt this change, that is very unlikely (well if Duke Nukem Forever has a release date now, then everything is possible :) Cheers -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Jan. 21, 2011

Re: [Pharo-project] Some important news

by laurent laffont

On Fri, Jan 21, 2011 at 8:26 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hi guys > > some important news today, we decided that we will set up a pharo > association > so that we can promote pharo. We would like to be able to collect money and > create bounties to improve pharo. > > great Laurent > Stef >

Jan. 21, 2011

Re: [Pharo-project] Gofer issue

by Igor Stasenko

On 21 January 2011 20:57, Miguel CobÃ¡ <miguel.coba(a)gmail.com> wrote: > El vie, 21-01-2011 a las 13:55 -0600, Miguel CobÃ¡ escribiÃ³: > >> Yes we understand, but that only applies to centralized SCM like >> subversion. >> In a distributed SCM like git and monticello the number means nothing. >> e.g. there could be two branches yours and mine, and both have 345 >> commits in it. Supposing that we don't skip any number and did nothing >> weird, there would be exactly 690 versions and bot >> Package-MiguelCoba.345.mcz and Package-IgorStasenko.345.mcz. If you did >> those 345 versions in one day and I did mines on a year, one for day, >> the only way to know which one is more "recent" is with timestamps. But >> the numbers means nothing in distributed SCMs. >> >> Cheers > > See, Git don't even use a number, it uses the SHA1 of the bytes that > were changed in the repository between commits. That is the most > unnumbered-sequentially way to mark a commit. For all practical purposes > it is a random number. > So lets do the same and get rid of numbers. So, name will be PackageName-SHA1.mcz everything else, like author and commit date is in package > Cheers > > > -- Best regards, Igor Stasenko AKA sig.

Jan. 21, 2011

Re: [Pharo-project] Gofer issue

by Igor Stasenko

On 21 January 2011 20:48, Miguel CobÃ¡ <miguel.coba(a)gmail.com> wrote: > This thing of the initial is really upsetting. > > I know that is old history and that even tools were made (monticello) > relying on them (even without specifying an accepted format, creating > more confusion) but I think that enough is enough. > > So, monticello hasn't a format for the filenames of the packages, at > least one that avoid problems due to initials, fullnames or whatever > string that the user happen to write in their image. > > For Igor, the problem is that he writes his name as Igor.Stasenko. That > chokes monticello and gofer and whatnot. I can tell you more. I am specifically using this name, because: when system asked me to enter initials, it wasn't warned me that my name is wrong or refused to use it and from that point, when something doesn't works because of my initials, this is NOT my fault. This is a fault of those tools, which put too much assumptions about what user could enter into text field when asked. So, lets fix the tools, instead of arguing , what convention should be. There should not be any convention about what i can use as my user name. I can choose to use Egyptian glyphs for initials. And don't force me to follow some scheme if its not necessary. > > Why don't we use the git way and let the user write two things, an email > and a free user name. And then sign the monticello packages with email > and in a meta-info inside the mcz (or in the commit info/message) use > the full name? > > What do you think? What it would break with a change like this? > > Cheers > -- Best regards, Igor Stasenko AKA sig.

Jan. 21, 2011