May 2014 - Pharo-dev - lists.pharo.org

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

by Tudor Girba

Hi, I really do not get the tone of these replies, but perhaps my mail was not clear. So, let me start over. You asked for who is interested in joining co-coding, and I said that I am interested particularly in the area of the logger. Specifically, I would be interested in splitting the Log class into two: - a Log class holding the current class side methods - a LogEvent (or LogEntry, or LogItem or whatever other name indicating the result of a single log statement) that holds the instance side of the current Log class. As it is now, when I execute: Log critical: 'message' I get an instance of Log. This is confusing, and not needed. We can nicely get an instance of LogEvent. This will not complicate things at all. Next, I said that as we already have a Zinc logging mechanism, I would be interested in consolidating Zinc to use the new mechanism. This would also provide a case study for having explicit classes of LogEvents and see the implications of that. And finally, I mentioned the Fuel serialization. My idea was to offer a cheap way to serialize a log into a file by serializing each log entry as a fuel object, but I did not know that we already have a JSON serialization. So, this is not that much of a priority anymore. I will propose code for the splitting. Doru On Wed, May 21, 2014 at 9:05 AM, stepharo <stepharo(a)free.fr> wrote: > > >>>> 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! > > > -- www.tudorgirba.com "Every thing has its own flow"

May 21, 2014

Re: [Pharo-dev] NativeBoost and WKHTML

by Sven Van Caekenberghe

Just out of curiosity, why not use Artefact, https://sites.google.com/site/artefactpdf ? I haven't looked at the different approaches, but I have this natural tendency against native libraries, if we can do it directly in Pharo. That is why I am asking: why this road and not the other ? On 21 May 2014, at 14:14, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > tried to wrap the WKHTML library (wkhtmltopdf.org) with NB to easily generate a PDF > using HTML from Pharo. I think this could serve as an easy printing solution > for Pharo. > > Code for an initial wrapper is on http://smalltalkhub.com/#!/~TorstenBergmann/WKHTML2PDF > with a simple class calling the component using NativeBoost. See class "WKPDFLibrary example" > I used Windows and the wkhtmltox.dll. > > The C example I follow with only a few function calls is very simple and can be found at > the bottom of: http://m.blog.csdn.net/blog/pengqianhe/8089007 > > The component is called, I get correct structs in return - but still no PDF file is generated. > Currently I cant see the forest for the trees. Maybe someone can have a short look what I'm > doing wrong. > > Thanks in advance > T. > > > > >

May 21, 2014

Re: [Pharo-dev] Understanding Workspace

by kilon alios

Thank you Tudor, thats looks definitely very useful . I am downloading it now and studying it :) On Wed, May 21, 2014 at 3:10 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > The first suggestion is to not invest in the PluggableTextMorph :) > > Ideally, we should get the new text widget soon, but in the meantime, you > would be better with using Rubric. It is a pragmatic solution developed by > Alain Plantec and that works now. This is where we are going with the > Glamorous Toolkit at the moment. You find it already in the Moose image, or > you can download it from here: > http://smalltalkhub.com/#!/~AlainPlantec/Rubric > > Cheers, > Doru > > > On Wed, May 21, 2014 at 12:44 PM, kilon alios <kilon.alios(a)gmail.com>wrote: > >> Hello guys, I have started a new experiment of mine, a tool I call >> "Talos". I want Talos to become workspace on steroids. >> >> The first thing I want to implement is emacs like navigation. With that I >> mean keyboard shortcuts for moving inside the text like you can do with >> arrow keys already and the ability to move to the next word , the first >> character of next word, the last character of next word , previous world, >> quickly rename variables and all the great things one can do with emacs and >> vim. >> >> Of course I don't want to do all that at once, one step at a time. >> >> Now I have take a look at Workspace and it seems that it uses >> PlaggableTextMorph , it also looks like I can get the contents via >> PluggableTextMorph>>text instance side. The source code returned is also >> send to RBParser using the parseBlock method , I think for syntax >> highlighting. >> >> However because the PluggableTextMorph is very big and it does not even >> have a class comment, though quite a lot of methods are commented, I am >> really open to advice and suggestions on to how to parse the contents and >> manipulate the cursor position. >> >> I know I could use PettitParser but I dont know if there are better >> options out there, or maybe I am doing the whole thing wrong. >> >> So any advice and suggestion is more than welcomed. >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

May 21, 2014

NativeBoost and WKHTML

by Torsten Bergmann

Hi, tried to wrap the WKHTML library (wkhtmltopdf.org) with NB to easily generate a PDF using HTML from Pharo. I think this could serve as an easy printing solution for Pharo. Code for an initial wrapper is on http://smalltalkhub.com/#!/~TorstenBergmann/WKHTML2PDF with a simple class calling the component using NativeBoost. See class "WKPDFLibrary example" I used Windows and the wkhtmltox.dll. The C example I follow with only a few function calls is very simple and can be found at the bottom of: http://m.blog.csdn.net/blog/pengqianhe/8089007 The component is called, I get correct structs in return - but still no PDF file is generated. Currently I cant see the forest for the trees. Maybe someone can have a short look what I'm doing wrong. Thanks in advance T.

May 21, 2014

Re: [Pharo-dev] Understanding Workspace

by Tudor Girba

The first suggestion is to not invest in the PluggableTextMorph :) Ideally, we should get the new text widget soon, but in the meantime, you would be better with using Rubric. It is a pragmatic solution developed by Alain Plantec and that works now. This is where we are going with the Glamorous Toolkit at the moment. You find it already in the Moose image, or you can download it from here: http://smalltalkhub.com/#!/~AlainPlantec/Rubric Cheers, Doru On Wed, May 21, 2014 at 12:44 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > Hello guys, I have started a new experiment of mine, a tool I call > "Talos". I want Talos to become workspace on steroids. > > The first thing I want to implement is emacs like navigation. With that I > mean keyboard shortcuts for moving inside the text like you can do with > arrow keys already and the ability to move to the next word , the first > character of next word, the last character of next word , previous world, > quickly rename variables and all the great things one can do with emacs and > vim. > > Of course I don't want to do all that at once, one step at a time. > > Now I have take a look at Workspace and it seems that it uses > PlaggableTextMorph , it also looks like I can get the contents via > PluggableTextMorph>>text instance side. The source code returned is also > send to RBParser using the parseBlock method , I think for syntax > highlighting. > > However because the PluggableTextMorph is very big and it does not even > have a class comment, though quite a lot of methods are commented, I am > really open to advice and suggestions on to how to parse the contents and > manipulate the cursor position. > > I know I could use PettitParser but I dont know if there are better > options out there, or maybe I am doing the whole thing wrong. > > So any advice and suggestion is more than welcomed. > -- www.tudorgirba.com "Every thing has its own flow"

May 21, 2014

Understanding Workspace

by kilon alios

Hello guys, I have started a new experiment of mine, a tool I call "Talos". I want Talos to become workspace on steroids. The first thing I want to implement is emacs like navigation. With that I mean keyboard shortcuts for moving inside the text like you can do with arrow keys already and the ability to move to the next word , the first character of next word, the last character of next word , previous world, quickly rename variables and all the great things one can do with emacs and vim. Of course I don't want to do all that at once, one step at a time. Now I have take a look at Workspace and it seems that it uses PlaggableTextMorph , it also looks like I can get the contents via PluggableTextMorph>>text instance side. The source code returned is also send to RBParser using the parseBlock method , I think for syntax highlighting. However because the PluggableTextMorph is very big and it does not even have a class comment, though quite a lot of methods are commented, I am really open to advice and suggestions on to how to parse the contents and manipulate the cursor position. I know I could use PettitParser but I dont know if there are better options out there, or maybe I am doing the whole thing wrong. So any advice and suggestion is more than welcomed.

May 21, 2014

Re: [Pharo-dev] The funny side of Pharo : Message Definitely Not Understood

by kilon alios

yeah I think "Update" needs to be removed from World Menu. Imagine first time trying Pharo and you exploring the World Menu which is the No 1 thing a newcomer does , you find Update and use it and BOOM! this happens. I would not blame that person if he / she says "fuck this" and removes Pharo from his/her system. Its not just that it brakes Pharo , it makes you really worried what else it may do to your system. I think also that even if its hidden it should always display a message like "Update may really brake your Pharo image, make sure you saved your image before proceeding . You want to save now ? " and offer an option to save image. Now with configurations being so popular maybe a method that will iterate through all Configurations , update them and then load their packages, may be the way to go for an update. That means that we need also to create some guidelines on how configurations should be created to make the experience smoother. On Wed, May 21, 2014 at 1:11 PM, stepharo <stepharo(a)free.fr> wrote: > We would love to have a real update but I'm sure that you realize that > something we > are modifying the system that modify the methods modifying the system. > > So we should probably remove the software update button. > Now if somebody wants to work on an infrastructure supporting real atomic > load. > > Stef > PS: the last time I updated my iPhone it blocked and I had to fully > reinstall everything. > And once when I updated my mac my mouse got blocked forever on the left > top corner. > > >

May 21, 2014

Re: [Pharo-dev] The funny side of Pharo : Message Definitely Not Understood

by stepharo

We would love to have a real update but I'm sure that you realize that something we are modifying the system that modify the methods modifying the system. So we should probably remove the software update button. Now if somebody wants to work on an infrastructure supporting real atomic load. Stef PS: the last time I updated my iPhone it blocked and I had to fully reinstall everything. And once when I updated my mac my mouse got blocked forever on the left top corner.

May 21, 2014

Re: [Pharo-dev] Grant for MetaRepoForPharo30

by stepharo

Copying is nice because people can load when they get to your repo. I systematically copy configuration. On 19/5/14 21:16, Maximiliano Taborda wrote: > Ready. You got it now. > > I decided to not update the config from the aconcagua repo, and > maintain up to date only the one in the meta repo, because I canÂ´t > find a way to publish the same config version to more than one repo > and I don't see the point of "copy" the same package in more than one > repo. > > If it doesn't exist the option, is a craziness thinking in publish to > more than one repo the same config just in one action? > > Regards. > Maxi. > > > 2014-05-19 15:06 GMT-03:00 Sean P. DeNigris <sean(a)clipperadams.com > <mailto:sean@clipperadams.com>>: > > Maximiliano Taborda wrote > > I want to publish Chalten and Aconcagua to the meta repo for 3.0. > > If it's safe, will you copy the config to > http://smalltalkhub.com/mc/maxi/Aconcagua/main/ (there is an outdated > version there now)? I'd like to depend on it in my project without > involving > meta repo for 3.0. In general I've found it's always a good idea > to keep > copies of configs with the main project because you never know how > users > will find you! Thanks :) > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Grant-for-MetaRepoForPharo30-tp4755362p4759574.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

May 21, 2014

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