- Pharo-dev - lists.pharo.org

Magritte versions

by Diego Lont

Hi all, We would like to have more communication about the Magritte configuration. We will start by describing the current state, as far as we know it. The current released version of Magritte is 3.1.3. This versions contains the latest changes and is a release version, so should not be changed. Please use #release3.1 in referring to this version, to allow for minor updates and bug fixes to be automatically integrated. The #release3.0 is also maintained, as this refers to #release3.0 of Seaside. And as long as #release3.1 of Seaside is not released on Gemstone, I will maintain this version. There is also versions 3.2. We do not know why this version is created. It uses a duplicate baseline (only the Grease version differs), and no big changes for Magritte are planned (to my knowledge). So we propose to remove this version. If you want this version to be kept, please reply this mail with a reason. Version 3.2 is outdated, but it implies to be more recent than 3.1.3. For the time being I will only remove the 3.2-baseline, as it is duplicate. If I do not receive a mail saying 3.2 should be kept, I will remove this version beginning of June. For development I will create a version 3.1.4. I will also point #development to this version. Discussion on Magritte List. Cheers, Stephan and Diego

May 21, 2014

Re: [Pharo-dev] Call for co-coders

by stepharo

Hi phil Have a look at - http://smalltalkhub.com/#!/~StephaneDucasse/SystemLogger - and the chapter :) https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… On 19/5/14 11:01, phil(a)highoctane.be wrote: > SystemLogger interests me as well. > > Phil > > On Mon, May 19, 2014 at 10:17 AM, Norbert Hartl <norbert(a)hartl.name > <mailto:norbert@hartl.name>> wrote: > > Hi Stef, > > Iâm definitely in for the SystemLogger. But as I am involved in it > anyway a fresh look from another person on that stuff could be > benefitial. > > Norbert > > Am 19.05.2014 um 09:10 schrieb stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > > Hi guys > > > > This is a call for some of you that committed code and would > like to do it with me :). > > I have some projects that I would like to push further in 4.0 > and I'm thinking that > > he could be much more fun to do it with other people. > > > > Here are some topics > > - integrating the systemLogger > > - integrating/improving the new method categorizer > > - cleaning fonts > > - ... > > > > How this could work? > > We could have > > - some discussions > > - make a little roadmap > > - then we could work on the same slice and do code review > > > > I think that it can be fun and motivating. So let me know > because I would like to have more social > > coding. > > > > Stef > > > > >

May 21, 2014

Re: [Pharo-dev] Pharo in Rasbian ?

by jannik laval

The point is that I am not so involved in the dev for raspbian. I do not tested sound and camera. Probably they should be recompiled for RPi. FileSystem is not stable because it depends on NativeBoost, not implemented for RPi for now. I added a fix for that, but it is not what I really want. So, before proposing it, we need to make it more stable, and cleaner. Cheers, Jannik 2014-05-20 17:43 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > Ah okay, this is an answer that I understand :-) > > We are not really good at promoting what we are doing. > For the the case of Rasbian, it seems not that difficult to have Phratch > and Pharo installed per default, if there is Scratch and Squeak. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On May 20, 2014, at 11:06 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > FFI for the raspberry pie was finished for the Pharo vm 3 weeks ago. > > > > So I guess the Phratch team has not found the time yet to do that, but > it should be possible. > > > > > -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/

May 21, 2014

Re: [Pharo-dev] Pharo in Rasbian ?

by jannik laval

Thank you JB for the answer. I am waiting for the integration :) Jannik 2014-05-20 18:41 GMT+02:00 Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> : > FFI for the raspberry pie was finished for the Pharo vm 3 weeks ago. > > Wait a second. Nope. > > FFI, have been implemented and integrated on CogVM repository by Doug > since 3 week, yes, not in Pharo repository. > There are small differences between CogVM and PharoVM. > A simple operation of extraction, installation, test , merge with the > stable pharoS-vm rasp. > > So 3 week ago I extracted the code of Doug from the CogVM repository, I > install it on my own jenkins. > But nothing is integrated yet, except in my repository. > Where also the OSProcess is currently tested. > > But no it is not in the latest pharos on raspberry. > > > > > On 20 May 2014, at 17:43, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > > Ah okay, this is an answer that I understand :-) > > We are not really good at promoting what we are doing. > For the the case of Rasbian, it seems not that difficult to have Phratch > and Pharo installed per default, if there is Scratch and Squeak. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On May 20, 2014, at 11:06 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > FFI for the raspberry pie was finished for the Pharo vm 3 weeks ago. > > So I guess the Phratch team has not found the time yet to do that, but it > should be possible. > > > > > > > Best Regards > Jean Baptiste Arnaud > jbaptiste.arnaud(a)gmail.com > > > > > > > > -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/

May 21, 2014

Configuration management Magritte and Pier

by Diego Lont

Hi all, I notice that for Grease and Seaside changes in the versions are always discussed on the Seaside list. Now maybe not all changes should be discussed, but for the major projects, like Magritte and Pier, I would like to have at least an announcement if a change is made in the configuration. To be more exact, I have no idea why version 3.2 was created in Magritte. I cannot find any mail on the list about this version. Secondly I would like people to use release versions of Grease, Seaside, Magritte and Pier as much as possible. I have introduced releases for Grease, Seaside, Magritte and Pier to all have a #âreleaseâ. These release âremoveâ the last index. So for Seaside the current released version is: 3.1.0.2. This means there is a #release3.1, referring to â3.1.0.2' and a #release3.0 referring to â3.0.12â. When there is an important bug fix, version 3.1.0.3 will be created with this fix, and release3.1 will point to that version. And when 3.1.1 is released, #release3.1 will point to this version. To be completely consistent, there should be a #release3.1.0 as well (referring to 3.1.0.2). There is also a #release3, that is the latest recommended release. As this is different for squeakCommon and gemstone at the moment, this is a special case for Seaside, but normally it would simply point to release3.1. It might be a good idea to introduce #releases to more configurations. Discussion on the Magritte list. Cheers, Diego

May 21, 2014

Re: [Pharo-dev] NewList without Icons

by Benjamin

On 21 May 2014, at 00:08, Nicolai Hess <nicolaihess(a)web.de> wrote: > Therefore, is there a way to create the NewList and tell it to NEVER > ask for icons? > As far as I remember I did not implement this option :) But having a flag for that should not be too complicated to add ;) Good luck, Ben

May 21, 2014

Re: [Pharo-dev] Call for co-coders

by stepharo

>>> >>> As a general matter, I would be interested in: >>> - unifying with the ZnLogEvent >> SystemLogger is infrastructure low level. So I do not see why Zn and SystemLogger should be unified. > If this means talking to Sven this is a definite yes. I donât think we > need to unify with the current ZnLogEvent. Syncing with zinc is > probably not the way to go anyway. Zinc is still an external framework > (hence the namespace prefix). I did a zinc bridge which operates an a > single event bridging from zinc to SystemLogger. This is not clever > performance wise. A better approach is to plug into zincs LogSupport. > We should hook into there so we just get the invocations from zinc and > we can emit the proper SystemLogger events into the Log framework. > Sven will come up with something announcement based. And that is still > a task for us, too. To look where functionality of SystemLogger is > doubled with announcements. We should pay attention that it stays small and simple. >> first we should integrate it and make sure that all the Transcript >> show are funnelled to the Log frameworks. > > Yes. Maybe we need to sync our understanding of log levels first. The > exchange adds a log level and adding a tag would be good, too. I do not get it but this is not a problem. No need to reply. >>> - Split the Log class >> >> we will not split it because we iterated over the design since 8 >> months with norbert :) > > I cannot find the proposals of Doru. But Iâm interested. I splitted > the Log class already into BasicLog and Log. Iâm not fully satisfied > with it so â¦ My concern about the Log class is more how get it right > supporting different kind of Log classes and still have a working > filtering in the Logger. But that we can discuss in the groups that > form I guess I would like to stop iterating. And again we should keep the system small. I studied all the logger framework available and I think that we can look for the graal forever or get done and I want to get done because there are other many many topics that can get fixed. Right now we went from 0% to 80% and this is a good ratio. We iterated with you. Now I do not want to pass time to go to an hypothetical 85%. >>> - Possibly support Fuel serialization for each log entry >> Please go ahead. > > Yes. I donât even understand what it means :) Send code!

May 21, 2014

Re: [Pharo-dev] Call for co-coders

by stepharo

For SystemLogger here is my roadmap steps - note that SystemLogger has a special logger that pushes strings to Transcript so we can have the same as now. - right now in Object we have crTrace crTrace: trace trace: traceCr traceCr: logCr: deprecated crLog: deprecated so we can use trace: (I do not like it that much but this is ok) - check all the Transcript left reference - convert them to use the SystemLogger probably to trace: so that after we can simply rewrite trace: - I think that it would be good to have a single entry point in Object (even at the cost to send another call to the main log recording method) - check all the log: - convert them (since a log is an entry we do not need to have explicit cr) - may be use a circular structure for holding entries because right now the logger logs as much as possible. - We should probably have different settings and the default should be circular - produce a nice transcript with structured log entries - log entries should be able to provide specific actions - for example a compiler logentry could hold a reference to the compiled method and we could ask to jump there - filter logentries - make sure that all the crLog: logCr: are nicely funnel to the systemLogger - and that everything works

May 21, 2014

Re: [Pharo-dev] Call for co-coders

by phil＠highoctane.be

On Wed, May 21, 2014 at 8:30 AM, stepharo <stepharo(a)free.fr> wrote: > Hi yuriy > > have a look at > > http://smalltalkhub.com/#!/~StephaneDucasse/AutomaticMethodCategorizer > > I should check again what I wanted to do before release and integration. > The point is not to make it too complex. > I would like to have much better rules and in fact I want to recategorise > the complete system with them > but we have to take care. > It would be nice to have a way to add typical protocols. e.g. Doing Seaside dev, add initialization/rendering/actions/... protocols. Now, I can always copy a "template" class, but it would be nice to have. Phil > > Stef > > On 19/5/14 15:08, Yuriy Tymchuk wrote: > >> Hi Stef (and all :)). >> >> Would be nice. Iâm anyway going to do something for Pharo and from time >> to time Iâm making small contributions here and there. As now Iâm working >> on code design/quality out of listed things I like method categoriser the >> most. But other options are acceptable. >> >> Uko >> >> On 19 May 2014, at 09:10, stepharo <stepharo(a)free.fr> wrote: >> >> Hi guys >>> >>> This is a call for some of you that committed code and would like to do >>> it with me :). >>> I have some projects that I would like to push further in 4.0 and I'm >>> thinking that >>> he could be much more fun to do it with other people. >>> >>> Here are some topics >>> - integrating the systemLogger >>> - integrating/improving the new method categorizer >>> - cleaning fonts >>> - ... >>> >>> How this could work? >>> We could have >>> - some discussions >>> - make a little roadmap >>> - then we could work on the same slice and do code review >>> >>> I think that it can be fun and motivating. So let me know because I >>> would like to have more social >>> coding. >>> >>> Stef >>> >>> >> >> >> > >

May 21, 2014

Re: [Pharo-dev] Call for co-coders

by Norbert Hartl

Am 21.05.2014 um 08:24 schrieb stepharo <stepharo(a)free.fr>: > > On 19/5/14 14:31, Tudor Girba wrote: >> Me too. I already gave a first set of feedback. >> >> As a general matter, I would be interested in: >> - unifying with the ZnLogEvent > If this means talking to Sven this is a definite yes. I donât think we need to unify with the current ZnLogEvent. Syncing with zinc is probably not the way to go anyway. Zinc is still an external framework (hence the namespace prefix). I did a zinc bridge which operates an a single event bridging from zinc to SystemLogger. This is not clever performance wise. A better approach is to plug into zincs LogSupport. We should hook into there so we just get the invocations from zinc and we can emit the proper SystemLogger events into the Log framework. Sven will come up with something announcement based. And that is still a task for us, too. To look where functionality of SystemLogger is doubled with announcements. > first we should integrate it and make sure that all the Transcript show are funnelled to the Log frameworks. Yes. Maybe we need to sync our understanding of log levels first. The exchange adds a log level and adding a tag would be good, too. >> - Split the Log class > > we will not split it because we iterated over the design since 8 months with norbert :) I cannot find the proposals of Doru. But Iâm interested. I splitted the Log class already into BasicLog and Log. Iâm not fully satisfied with it so â¦ My concern about the Log class is more how get it right supporting different kind of Log classes and still have a working filtering in the Logger. But that we can discuss in the groups that form I guess > >> - Possibly support Fuel serialization for each log entry > Please go ahead. Yes. I donât even understand what it means :) Norbert >> >> Doru >> >> >> On Mon, May 19, 2014 at 11:01 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >> SystemLogger interests me as well. >> >> Phil >> >> >> On Mon, May 19, 2014 at 10:17 AM, Norbert Hartl <norbert(a)hartl.name> wrote: >> Hi Stef, >> >> Iâm definitely in for the SystemLogger. But as I am involved in it anyway a fresh look from another person on that stuff could be benefitial. >> >> Norbert >> >> Am 19.05.2014 um 09:10 schrieb stepharo <stepharo(a)free.fr>: >> >> > Hi guys >> > >> > This is a call for some of you that committed code and would like to do it with me :). >> > I have some projects that I would like to push further in 4.0 and I'm thinking that >> > he could be much more fun to do it with other people. >> > >> > Here are some topics >> > - integrating the systemLogger >> > - integrating/improving the new method categorizer >> > - cleaning fonts >> > - ... >> > >> > How this could work? >> > We could have >> > - some discussions >> > - make a little roadmap >> > - then we could work on the same slice and do code review >> > >> > I think that it can be fun and motivating. So let me know because I would like to have more social >> > coding. >> > >> > Stef >> > >> >> >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >

May 21, 2014