- Pharo-dev - lists.pharo.org

Re: [Pharo-project] eating some obsolete dog food

by Igor Stasenko

:) On 7 December 2012 23:59, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > This is a long time since I did not contribute to Pharo, so I tried > with something easy... > http://code.google.com/p/pharo/issues/detail?id=7108 > > I downloaded latest successful build, > Pharo2.0a > Latest update: #20433 > > Then I updated the 5 methods from a MC merge, and... > Err... I cannot type my initials ^H^H^H^H^H^H^H^H full name > The dialog insists on selecting any letter I type and next letter will > override the previous one. > I finally published anonymously, that does not matter... > > But you know the impact of a first bad UI impression... > It would ruin tons of efforts I know you spent cleaning the infrastructure. > I believe such cleaning is very ambitious and rarely rewarding in the > short term... > But I'd really like to be more supportive, it's so essential for > building the future. > > So before ranting loud, I digged a bit further: could it be this > warning I had at startup about obsolete VM, yes that was it! > So if you are episodic user like me : > > ******** DON'T FORGET TO DOWNLOAD A PHARO SPECIFIC VM ************* > > I already spent way more time on this than I wished, hope my mistake > helps someone else. > ( over-estimating pharo planned obsolescence period is indeed a > mistake ;) why would the VM be handled differently ? ) > > Last thing, maybe you should insist on the download page that 2.0 > REQUIRES a pharo specific VM. > Not sure I would have read it, but then it would be entirely my fault. > Yes, we should mention that, especially since 2.0 now entered beta stage. But apart from this, i am really surprised that you was unable to upload MC package with 'obsolete' VM.. That warning is really just a complaint that you should get more recent VM. And unless you using file browser (which won't function properly on older vms) the other parts of system should work well. At least, this is what i experienced.. but since my development image is 2-3 months behind bleeding edge, (and only few days ago i migrated to most recent one), i cannot guarantee if it still like that i saying :) > Nicolas -- Best regards, Igor Stasenko.

Dec. 8, 2012

[Pharo-project] eating some obsolete dog food

by Nicolas Cellier

This is a long time since I did not contribute to Pharo, so I tried with something easy... http://code.google.com/p/pharo/issues/detail?id=7108 I downloaded latest successful build, Pharo2.0a Latest update: #20433 Then I updated the 5 methods from a MC merge, and... Err... I cannot type my initials ^H^H^H^H^H^H^H^H full name The dialog insists on selecting any letter I type and next letter will override the previous one. I finally published anonymously, that does not matter... But you know the impact of a first bad UI impression... It would ruin tons of efforts I know you spent cleaning the infrastructure. I believe such cleaning is very ambitious and rarely rewarding in the short term... But I'd really like to be more supportive, it's so essential for building the future. So before ranting loud, I digged a bit further: could it be this warning I had at startup about obsolete VM, yes that was it! So if you are episodic user like me : ******** DON'T FORGET TO DOWNLOAD A PHARO SPECIFIC VM ************* I already spent way more time on this than I wished, hope my mistake helps someone else. ( over-estimating pharo planned obsolescence period is indeed a mistake ;) why would the VM be handled differently ? ) Last thing, maybe you should insist on the download page that 2.0 REQUIRES a pharo specific VM. Not sure I would have read it, but then it would be entirely my fault. Nicolas

Dec. 7, 2012

Re: [Pharo-project] [ANN] Pharo 2.0 enters BETA

by Tudor Girba

Hi, On 6 Dec 2012, at 22:22, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Dec 6, 2012, at 8:37 PM, Tudor Girba wrote: > >> Great. >> >> We will release Moose 4.7 on top of Pharo 1.4 soon (probably next week or so), and afterwards we will immediately switch to Pharo 2.0. > > Doru I will try sunday to concentrate and see if I can understand the bug in metacello I got. That would be really great. Doru > >> >> Cheers, >> Doru >> >> >> On 6 Dec 2012, at 18:10, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> Hi, >>> >>> Today I finished the pending integrations for move to Pharo 2.0. >>> There is still a problem with the VMs (for NB), but that's not a stopper for moving on. >>> >>> What does this means? >>> Starting now, no new changes of API will be allowed, just bug fixes and minor enhancements that does not change the system behavior. >>> We still have a long stabilization path until we can release, but we hope a couple of months will put us in shape :) >>> >>> Esteban >> >> -- >> www.tudorgirba.com >> >> "Presenting is storytelling." >> >> > > -- www.tudorgirba.com "We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality."

Dec. 7, 2012

Re: [Pharo-project] NBFFICallback fnSpec

by Jimmie Houchin

On 12/6/2012 1:29 AM, Igor Stasenko wrote: > On 5 December 2012 22:28, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >> Hello, >> >> In one of my callbacks I have an fnSpec with an enum. >> >> ^#( void (enum sessionStatus)) >> >> from >> >> typedef void (*SESSION_STATUS_CALLBACK)(O2GSessionStatus eSessionStatus); >> >> How are enums handled in NB? >> What would be the proper type for the fnSpec and how do I access the values >> in an enum in my class? > enums are unsigned integer values , so you must change the signature > to use 'uint' > or 'uint32' type. > Then make a shared pool with constants , initialize them with proper values > and you done. Thank you very much. You have been a great help. And thank you for taking on the initiative for this vital infrastructure project. I think you are very right in your video. It is a lot of fun to do low level programming in a high level language. Thanks for making this possible. Jimmie

Dec. 7, 2012

Re: [Pharo-project] Progress Update

by Igor Stasenko

please fix the progress bars. i downloaded latest image today and it blocks all existing windows from being accessible. the only cure i found is tell world to remove all windows. new windows working normally. -- Best regards, Igor Stasenko.

Dec. 7, 2012

Re: [Pharo-project] [RFC] Zinc-Resources

by Igor Stasenko

On 7 December 2012 20:47, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > This is request for comment on an idea, as suggested by Pavel because he needs it for his kernel building/packaging work, but also in line with several existing issues related to URL, URI and mime types. > > The idea would be to create a new package called 'Zinc-Resources' or maybe 'Zinc-Resource-Description' to contain just ZnUrl and ZnMimeType (and their supporting clases if any). The packaging requirement would be that the new package can only depend on core Smalltalk and not on any IO related packages such as File, Network or HTTP (Zn). Afterwards, File, Network or HTTP (Zn) could then add extensions, like #retrieveContents. > > After the separation I would like to extend ZnUrl to at least support file URIs (file://) since these are very useful. I am not sure that extending ZnUrl to be more general and to satisfy all users will be easy, I fear some conflicting goals, but we'll see. > > The end goal is of course to replace the old classes and simply Pharo. > > Any comments ? > No comments. Do it. :) yeah. we could have a simple registry for schema handlers and for mime handlers.. so, other packages can add own handlers to either of them. as result, no tight coupling. > Sven > > PS: Of course, there would be a unit tests package as well. Actually, any changes should be test driven. > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > -- Best regards, Igor Stasenko.

Dec. 7, 2012

Re: [Pharo-project] [RFC] Zinc-Resources

by StÃ©phane Ducasse

On Dec 7, 2012, at 8:47 PM, Sven Van Caekenberghe wrote: > Hi, > > This is request for comment on an idea, as suggested by Pavel because he needs it for his kernel building/packaging work, but also in line with several existing issues related to URL, URI and mime types. > > The idea would be to create a new package called 'Zinc-Resources' or maybe 'Zinc-Resource-Description' to contain just ZnUrl and ZnMimeType (and their supporting clases if any). The packaging requirement would be that the new package can only depend on core Smalltalk and not on any IO related packages such as File, Network or HTTP (Zn). Afterwards, File, Network or HTTP (Zn) could then add extensions, like #retrieveContents. > > After the separation I would like to extend ZnUrl to at least support file URIs (file://) since these are very useful. I am not sure that extending ZnUrl to be more general and to satisfy all users will be easy, I fear some conflicting goals, but we'll see. I would really like to have one good URL/URI class and I like the idea proposed by pavel/you! > > The end goal is of course to replace the old classes and simply Pharo. > > Any comments ? > > Sven > > PS: Of course, there would be a unit tests package as well. Actually, any changes should be test driven. > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > >

Dec. 7, 2012

Re: [Pharo-project] Progress Update

by StÃ©phane Ducasse

On Dec 7, 2012, at 7:17 PM, Camillo Bruni wrote: > > On 2012-12-06, at 18:14, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Camillo I do not know. >> Now I will have a look at your change because I was also fixing a bit the progressBar class. Removing some useless methods >> and I grouped all the job class under >> kernel-job >> and progressbar under >> morphic progress bar because I was fed up to see them in process and system support mixed with other. > > ok, that looks fine :) separate packages should clarifiy things a bit :) I could not separate the packages because we found a bug in rpackage integration. > Maybe I have time to look into it, today. Otherwise I won't touch the computer for 7 days :P and enjoy the georgious argentinian country side! > >>> > there should be no more min-max, hence no more 0 divide possible. > But yeah, I got a bit lost in fixing the UI part ;) so I still have to > do the proper transformations on the rest of the image. I see what you mean because there are plenty of places where it is based on size. I will try to integrate my changes with progressBar (I try to fix the size problem but it often depends on the users). Stef

Dec. 7, 2012

[Pharo-project] [RFC] Zinc-Resources

by Sven Van Caekenberghe

Hi, This is request for comment on an idea, as suggested by Pavel because he needs it for his kernel building/packaging work, but also in line with several existing issues related to URL, URI and mime types. The idea would be to create a new package called 'Zinc-Resources' or maybe 'Zinc-Resource-Description' to contain just ZnUrl and ZnMimeType (and their supporting clases if any). The packaging requirement would be that the new package can only depend on core Smalltalk and not on any IO related packages such as File, Network or HTTP (Zn). Afterwards, File, Network or HTTP (Zn) could then add extensions, like #retrieveContents. After the separation I would like to extend ZnUrl to at least support file URIs (file://) since these are very useful. I am not sure that extending ZnUrl to be more general and to satisfy all users will be easy, I fear some conflicting goals, but we'll see. The end goal is of course to replace the old classes and simply Pharo. Any comments ? Sven PS: Of course, there would be a unit tests package as well. Actually, any changes should be test driven. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 7, 2012

Re: [Pharo-project] Progress Update

by Camillo Bruni

On 2012-12-06, at 18:14, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Camillo I do not know. > Now I will have a look at your change because I was also fixing a bit the progressBar class. Removing some useless methods > and I grouped all the job class under > kernel-job > and progressbar under > morphic progress bar because I was fed up to see them in process and system support mixed with other. ok, that looks fine :) separate packages should clarifiy things a bit :) Maybe I have time to look into it, today. Otherwise I won't touch the computer for 7 days :P and enjoy the georgious argentinian country side! >> I promised to fix my partial refactoring for the ProgressBar. >> Finally this evening I hacked on the whole progress mess :), now I am almost done with one little bug left.\\ > > Cool you are addicted! > >> - the progress bar is always responsive >> - all processes showing a progress with priority <60 can be interrupted >> - refreshes periodically 16 times per second >> - only forces a manual refresh when blocking the UI >> - no more out of bounds progress bars >> - no more ugly display buffer pattern when resizing the screen during a running progress >> >> this is a massive improvement for me :) For instance now you can simply interrupt the test runner >> with a click on the progress bar. > > Did you check that it works with 1 to: 1 because in the past I got a zeroDivide there should be no more min-max, hence no more 0 divide possible. But yeah, I got a bit lost in fixing the UI part ;) so I still have to do the proper transformations on the rest of the image.

Dec. 7, 2012