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

[Pharo-project] [update 3.0] #30105

by Marcus Denker

30105 ----- 10253 Unrecoverable error when deleting methods https://pharo.fogbugz.com/f/cases/10253 10525 Spec key navigation improved https://pharo.fogbugz.com/f/cases/10525 10531 DropListMorph can not be searched through using keyboard https://pharo.fogbugz.com/f/cases/10531 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-MarcusDenker.142… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Core-MarcusDenker.109.di… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Ring-Core-Kernel-MarcusDenker… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-MarcusDenker.1416.diff

May 6, 2013

Re: [Pharo-project] Sprint

by Damien Cassou

On Sat, May 4, 2013 at 12:11 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > We fixed a lot of things today (incomplete list, please extend): - tree rewriter now just works in nautilus - classes are indented properly -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

May 6, 2013

Re: [Pharo-project] WhatsUp from: 2013-05-06 until: 2013-05-19

by Guillermo Polito

On Mon, May 6, 2013 at 7:00 AM, <seaside(a)rmod.lille.inria.fr> wrote: > Hi! We're sending this automatic email twice a month, to give the > community an opportunity to easily know what's happening and to coordinate > efforts. Just answer informally, and feel free to spawn discussions > thereafter! > > ### Here's what I've been up to since the last WhatsUp: > > - Bootstrap - Added comments into MCRepository & subclasses - Making configurable MCDirectoryRepository - Keymappings cleansings, lots of comments and global shortcuts - mapping platform specific keycodes to a common keycode base, for keyup and keydown events > > ### What's next, until 2013-05-19 (*): > > - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION > > (*) we'll be expecting results by then ;) > >

May 6, 2013

Re: [Pharo-project] WhatsUp from: 2013-05-06 until: 2013-05-19

by Max Leske

On 06.05.2013, at 07:00, seaside(a)rmod.lille.inria.fr wrote: > Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! > > ### Here's what I've been up to since the last WhatsUp: > - Fixed a bug in Fuel - added graph modification enhancement to Fuel - started work on LibGit bindings > > ### What's next, until 2013-05-19 (*): > - finalize the bug fix for Fuel - continue working on LibGit bindings. Next goal: createing new commits > > (*) we'll be expecting results by then ;) >

May 6, 2013

Re: [Pharo-project] WhatsUp from: 2013-05-06 until: 2013-05-19

by Esteban Lorenzano

On May 6, 2013, at 7:00 AM, seaside(a)rmod.lille.inria.fr wrote: > Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! > > ### Here's what I've been up to since the last WhatsUp: - working on vm bugs and jenkins builds - working on nb-objc bridge - a bit on the association site (internals) - pharo bugs and new integration tool > ### What's next, until 2013-05-19 (*): - holidays - more nb-objc - more new integration tool - new class organizer integration

May 6, 2013

Re: [Pharo-project] Pharo Logo SVG

by Marcus Denker

On May 4, 2013, at 12:39 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> > > The previous version was findable from our websiteâ¦ > > http://www.pharo-project.org/pharo-download/media-files > > I will clean this page up (added a TODO, will add a tracker entry). > Updated: http://www.pharo-project.org/pharo-download/media-files Marcus

May 6, 2013

Re: [Pharo-project] about logCr: vs. log: vs. trace:/traceCr:

by Dennis Schetinin

+1! That's I wanted to come to, just step by step, by introducing level as an object first, then format, and so on. -- Best regards, Dennis Schetinin 2013/5/6 Norbert Hartl <norbert(a)hartl.name> > > Am 06.05.2013 um 08:00 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: > > Hello. > > What about logging levels? > > I like "logInfo:", "logDebug:", "logTrace:". Or maybe it is better to > split log with levels: "self log info:", "self log debug:", "self log > trace:" > > I think that opens a can of worms. What Stef wants is a "say something" > method that is easy to use and commonly useful. Adding logging levels is a > specialized form of logging that is not commonly useful, it's just commonly > used in less reflective environments. > So my proposal would be to have an equivalent to "self log" where you can > return your own logging facility on which you can do "self log info: > 'something'". > > I changed my kind of logging some time ago. I just log objects. A log > object isn't much more than to put it on top of a collection. While I'm not > using strings for logging I have objects where I can attach all my use case > dependent stuff. You could even put something like a log level information > in those objects. > I log Errors as well as progress state objects,etc. It is easy to process > the whole log collection (now or afterwards) because all necessary state is > still there. > Another reason why I don't like strings for that is that I put the log > messages as json in elasticsearch/mongo because I want to query them to > find errornous behaviour. Well, sometimes I do both: Store it in a database > and write it to disk. Because I don't convert it to a string at first > possible time I can do that easily. > > We don't put sources in files so we shouldn't put log information only > there. Make logging information a first class citizen! > > Norbert > > Best regards, > Denis > > 2013/5/5 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> Hi guys >> >> Stupidly I introduced log: a while ago to replace Transcript show:. Now >> is the current situation. >> >> I still want to remove all the use of Transcript show: >> >> Now since I thought I did a mistake with log: because it overload >> Integer>>log: I introduced trace: and traceCr: >> >> Now I do not like traceCr: because it is not a cool message. >> >> So what do we do: >> >> 1) we use crLog:, logCr: >> and deprecated log: >> >> >> 2) we use crTrace:, trace: and traceCr: >> >> I really prefer solution 1 but I would like to hear from you. >> >> Stef >> > > >

May 6, 2013

Re: [Pharo-project] about logCr: vs. log: vs. trace:/traceCr:

by Norbert Hartl

Am 06.05.2013 um 08:00 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: > Hello. > > What about logging levels? > > I like "logInfo:", "logDebug:", "logTrace:". Or maybe it is better to split log with levels: "self log info:", "self log debug:", "self log trace:" > I think that opens a can of worms. What Stef wants is a "say something" method that is easy to use and commonly useful. Adding logging levels is a specialized form of logging that is not commonly useful, it's just commonly used in less reflective environments. So my proposal would be to have an equivalent to "self log" where you can return your own logging facility on which you can do "self log info: 'something'". I changed my kind of logging some time ago. I just log objects. A log object isn't much more than to put it on top of a collection. While I'm not using strings for logging I have objects where I can attach all my use case dependent stuff. You could even put something like a log level information in those objects. I log Errors as well as progress state objects,etc. It is easy to process the whole log collection (now or afterwards) because all necessary state is still there. Another reason why I don't like strings for that is that I put the log messages as json in elasticsearch/mongo because I want to query them to find errornous behaviour. Well, sometimes I do both: Store it in a database and write it to disk. Because I don't convert it to a string at first possible time I can do that easily. We don't put sources in files so we shouldn't put log information only there. Make logging information a first class citizen! Norbert > Best regards, > Denis > > 2013/5/5 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Hi guys > > Stupidly I introduced log: a while ago to replace Transcript show:. Now is the current situation. > > I still want to remove all the use of Transcript show: > > Now since I thought I did a mistake with log: because it overload Integer>>log: I introduced trace: and traceCr: > > Now I do not like traceCr: because it is not a cool message. > > So what do we do: > > 1) we use crLog:, logCr: > and deprecated log: > > > 2) we use crTrace:, trace: and traceCr: > > I really prefer solution 1 but I would like to hear from you. > > Stef >

May 6, 2013

Re: [Pharo-project] about logCr: vs. log: vs. trace:/traceCr:

by Sven Van Caekenberghe

On 06 May 2013, at 08:00, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > I like "logInfo:", "logDebug:", "logTrace:". Or maybe it is better to split log with levels: "self log info:", "self log debug:", "self log trace:" That is actually the interface that I use, as implemented in Zinc-HTTP-Logging, together with optional block arguments. Here is a simple example: logRequest: request "Log a request that was just read" self log info: [ lastRequest := request. 'Read ', request printString ] And a more complicated one (transaction is also a log level here): logRequest: request response: response started: initialMilliseconds self log transaction: [ String streamContents: [ :stream | request requestLine printMethodAndUriOn: stream. stream space; print: response code. response hasEntity ifTrue: [ stream space; print: response entity contentLength; nextPut: $B ]. stream space; print: (Time millisecondsSince: initialMilliseconds); nextPutAll: 'ms' ] ] I think it is really useful that the block is not executed when logging is disabled. Another advantage of block arguments is that there can be an error handler around its evaluation: errors while logging are very annoying and are better handled automatically. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

May 6, 2013

Re: [Pharo-project] about logCr: vs. log: vs. trace:/traceCr:

by Norbert Hartl

Am 05.05.2013 um 21:42 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi guys > > Stupidly I introduced log: a while ago to replace Transcript show:. Now is the current situation. > > I still want to remove all the use of Transcript show: > > Now since I thought I did a mistake with log: because it overload Integer>>log: I introduced trace: and traceCr: > > Now I do not like traceCr: because it is not a cool message. > > So what do we do: > > 1) we use crLog:, logCr: > and deprecated log: > > > 2) we use crTrace:, trace: and traceCr: > > I really prefer solution 1 but I would like to hear from you. I assume crLog:/logCr: is a short and convenient form of something else. How would these be called? Basically I want to log objects and only the default in Object should use Transcript in combination with "asString". On top of the short form a convenient selector that adds a line ending makes sense. There needs to be a getter for a log where one can attach all needs like logging levels, log destinations, etc. So is the plan to have only the direct replacement for "Transcript show:" or something that can be extended/used differently. And why do we use cr? I think it is pretty common to us NL = newline. Where does this come from? Logically a "carriage return" enables you only to print something in bold while newline enables you to print a whole page :) Norbert

May 6, 2013