April 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [HELP WANTED] Getting ready for Pharo 5.0 release (CentOS, oldLibC, Nix, ArchLinux, and others)

by philippe.back＠highoctane.be

Will do the CentOS 6 thing. And give a shot at CentOS 7. That one may take longer. Phil On Apr 27, 2016 3:26 PM, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: > Hi, > > Iâm trying to get ready the download page for Pharo 5.0â¦ who should happen > next monday :) > So, I create a download page: > > http://pharo.org/download-50 > > and one for linux: > > http://pharo.org/gnu-linux-installation-50 > > For linux, I made > > linux general > centos > oldLibC > > but > > 1) I cannot test them > 2) list is incomplete, we are still missing: > - ubuntu ppa > - Nix > - ArchLinux > > Can responsables for those platforms take action and test/prepare packages? > > thanks! > > Esteban > > >

April 27, 2016

Happy with Pharo 5.0 release!

by Mariano Martinez Peck

Hi guys, This is just to let you know I am very happy with Pharo 5.0 upcoming release. I was already used quite a lot for other projects (OSSubprocess etc), but a couple of days ago, I started to develop my client's app (Quuve) and so far so great. It only took me an hour or so to update all my dependencies in my Metacello conf (I have a lot of dependencies). So..thanks for all those who have been updating their confs! I was already familiar with all the GT tools so I was happy with that. I really notice a speed up (I guess in big part thanks to Spur) and so far it was quite robust. I also noticed some memory leak fixing...as previously in 4.0 I was re-building images all the time because I get to 500MB in no time. Right now I keep using the same image as for several days and so far no problem with memory. Finally...let me say.... if for Pharo 6.0 we finally get Git support directly integrated into the image and we get expected Sista speedup, I think it will be the best release ever hahahahha. Thanks for all your efforts and congratulations for the upcoming release. I am already enjoying it since several weeks already. -- Mariano http://marianopeck.wordpress.com

April 27, 2016

Re: [Pharo-dev] [HELP WANTED] Getting ready for Pharo 5.0 release (CentOS, oldLibC, Nix, ArchLinux, and others)

by Esteban Lorenzano

> On 27 Apr 2016, at 15:31, Damien Cassou <Damien.Cassou(a)inria.fr> wrote: > > Esteban Lorenzano <estebanlm(a)gmail.com> writes: > >> - ubuntu ppa > > the ubuntu ppa package is Pharo 4 only as of now it shouldnât :) > >> - Nix > > in nix we have both pharo 4 and pharo 5 VMs. I use both everyday. cool :) > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill

April 27, 2016

Re: [Pharo-dev] [HELP WANTED] Getting ready for Pharo 5.0 release (CentOS, oldLibC, Nix, ArchLinux, and others)

by Damien Cassou

Esteban Lorenzano <estebanlm(a)gmail.com> writes: > - ubuntu ppa the ubuntu ppa package is Pharo 4 only as of now > - Nix in nix we have both pharo 4 and pharo 5 VMs. I use both everyday. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

April 27, 2016

[HELP WANTED] Getting ready for Pharo 5.0 release (CentOS, oldLibC, Nix, ArchLinux, and others)

by Esteban Lorenzano

Hi, Iâm trying to get ready the download page for Pharo 5.0â¦ who should happen next monday :) So, I create a download page: http://pharo.org/download-50 and one for linux: http://pharo.org/gnu-linux-installation-50 For linux, I made linux general centos oldLibC but 1) I cannot test them 2) list is incomplete, we are still missing: - ubuntu ppa - Nix - ArchLinux Can responsables for those platforms take action and test/prepare packages? thanks! Esteban

April 27, 2016

Re: [Pharo-dev] Logging API discussion

by Robert Withers

I'd like to mention my TraceEvent and TraceMonitor classes, again, as it supports most of what you guys are talking about. I believe I have resolved my package naming, so you can find these classes in the SqueakSource's Cryptography repository in the OCapPresents package. TraceEvent is a single loggable event class with timestamp ivar, generic msg ivar, filterable domain ivar, remote ivar. These ivars are converted to strings during logEvent handling in the monitor, so the msg ivar can hold a user-defined loggable event objects that convert to a preferred string. There would be no need to write separate wrappers for each use. The monitor can have various domains enabled or disabled: use TraceMonitor>>#enableDomain:/#disableDomain: with a symbol. My use has a bunch of convenience methods for my domain use, but a new domain can be added and one can use the #etrace:msg: variety, which accepts the domain as the first parameter and the domain specific msg object as the second parameter. The monitor can write to multiple trace streams. I am missing logLevel, though I tried to add severity but it is non-functional. It would be easy enough to add. I do not know if this aligns with the Announcements solution you all are talking about or if it meets all your needs. It is sounding like it meets most of the logging domain information, it is filterable, has multiple output streams, uses the event system so it is lightly couple to the domain. Whatever solution is arrived at, I hope it is a shared infrastructure service in squeak as well, along with Fuel, then I would likely switch to using the standard. On 04/27/2016 08:16 AM, Denis Kudriashov wrote: > 2016-04-27 10:43 GMT+02:00 Norbert Hartl <norbert(a)hartl.name > <mailto:norbert@hartl.name>>: > > I must confess I cannot follow you completely. What we were/are > talking about is that the assumption a logging entry needs > timestamp, log level and such is not appropriate. If you have > legacy syslog style logging in mind it appears natural but for a > lot of use cases it is not. > > > Could you provide example where it is not? > > Even if you could say that a timestamp is part of the logging > domain it is not said if that timestamp needs to be part of the > log object or the logger consuming this object. This question > arises for every quality of a logging object. Even the logging > level could be some behavioral quality that a logger matches to > log levels. Contrary to this is logging thisContext which has to > be done in the log object. > I think the hard part is the way of distribution of log objects > and filtering of them. While the former is being discussed with > Beacon the latter is mostly ignored while being really important. > Not having default qualities of a log object is good on one hand > but on the other hand the filtering is much harder. > In SystemLogger we didn't go far enough at first. The Log class > contained level and such. That was the reason for me to split it > into BasicLog consisting of timestamp and a message object and Log > which contains the extra qualities. > > > My problem with such approach is that it forces me to create hierarchy > of log events as subclasses of base log component. > Imaging that my application already provide hierarchy of events but > they have no timestamps. How to log them? Should I use some > WrapperSignal? > Now imaging that application uses some library which provides events > too. But this events are log entries themselves. What I will see in my > logs? > I will see mix of WrapperSignal's and normal events. It would be not > easy to analize such log. > > That's why I want unified log entries. I would model it with single > class LogEntry which nobody needs to subclass. It would contain > logging domain information: timestamp, importance level, user message > and whatever. And it would have *content *property to keep logging > object. So our tools can rely on this structure to make it easy to > work with logs. And when anybody will look at particular log he will > be sure that logging object is inside "content" variables of each record -- Robert . .. ... ^,^

April 27, 2016

Re: [Pharo-dev] Logging API discussion

by Denis Kudriashov

2016-04-27 14:16 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > My problem with such approach is that it forces me to create hierarchy of > log events as subclasses of base log component. > Imaging that my application already provide hierarchy of events but they > have no timestamps. How to log them? Should I use some WrapperSignal? > Now imaging that application uses some library which provides events too. > But this events are log entries themselves. What I will see in my logs? > I will see mix of WrapperSignal's and normal events. It would be not easy > to analize such log. > And also it makes difficult to filter such logs. For library events I can use announcements approach directly (for example). But for application events it would not work because they are inside wrappers

April 27, 2016

Re: [Pharo-dev] Logging API discussion

by Denis Kudriashov

2016-04-27 10:43 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > I must confess I cannot follow you completely. What we were/are talking > about is that the assumption a logging entry needs timestamp, log level and > such is not appropriate. If you have legacy syslog style logging in mind it > appears natural but for a lot of use cases it is not. > Could you provide example where it is not? > Even if you could say that a timestamp is part of the logging domain it is > not said if that timestamp needs to be part of the log object or the logger > consuming this object. This question arises for every quality of a logging > object. Even the logging level could be some behavioral quality that a > logger matches to log levels. Contrary to this is logging thisContext which > has to be done in the log object. > I think the hard part is the way of distribution of log objects and > filtering of them. While the former is being discussed with Beacon the > latter is mostly ignored while being really important. Not having default > qualities of a log object is good on one hand but on the other hand the > filtering is much harder. > In SystemLogger we didn't go far enough at first. The Log class contained > level and such. That was the reason for me to split it into BasicLog > consisting of timestamp and a message object and Log which contains the > extra qualities. > My problem with such approach is that it forces me to create hierarchy of log events as subclasses of base log component. Imaging that my application already provide hierarchy of events but they have no timestamps. How to log them? Should I use some WrapperSignal? Now imaging that application uses some library which provides events too. But this events are log entries themselves. What I will see in my logs? I will see mix of WrapperSignal's and normal events. It would be not easy to analize such log. That's why I want unified log entries. I would model it with single class LogEntry which nobody needs to subclass. It would contain logging domain information: timestamp, importance level, user message and whatever. And it would have *content *property to keep logging object. So our tools can rely on this structure to make it easy to work with logs. And when anybody will look at particular log he will be sure that logging object is inside "content" variables of each record

April 27, 2016

Re: [Pharo-dev] Logging API discussion

by Denis Kudriashov

Hi Norbert 2016-04-27 10:43 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > So assuming the Log class would not contain log levels but SysLog would do > you could easily override #logClass in your domain object and use it this > way > > MyDomainClass class>>#logClass > ^ SysLog > > myDomainObject asLog > warning; > emit > > This way we do not need to pollute Object with a lot of methods that are > tight to one use case. The call to #warning could be something else that > only depends on the Log class you want to use. > There is one problem with this approach when we split preparation and emitting of log object. It will always produce garbage. If no logs will have interest in myDomainObject or #warning-level messages application will continue create log entries. I think it is important to minimize cost of logging when nobody have interest on particular event. If debug-level log is disabled then no garbage should be created. If stack traces log is disabled then no stack information should be retrieved anywhere. To achieve this we should create log entry instances only when we will find any logs for them. It imposes restriction on possible API. At point when we are ready to log something we should have all information which can be part of filter. So if we want to filter logs by domain objects and log-levels we need both parameters in one message send. Then we can ask every registered log for interest about both of them. And only when we will find any one we will create log entry instance for them.

April 27, 2016

[pharo-project/pharo-core] 2a4187: 50723

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 2a4187f4040254cb31d2fc7b5f2f4158a9a296e1 https://github.com/pharo-project/pharo-core/commit/2a4187f4040254cb31d2fc7b… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-04-27 (Wed, 27 Apr 2016) Changed paths: M AST-Core.package/RBParser.class/class/parsing/parseMethod_onError_.st M AST-Core.package/RBParser.class/instance/error handling/parserError_.st M CodeImport.package/FileCompilerRequestor.class/instance/interactive error protocol/notify_at_in_.st M CodeImport.package/MethodChunk.class/instance/importing/importFor_.st A CodeImport.package/MethodChunk.class/instance/importing/methodCompileRequestorFor_.st A CodeImport.package/MethodChunkCompilerRequestor.class/README.md A CodeImport.package/MethodChunkCompilerRequestor.class/definition.st A CodeImport.package/MethodChunkCompilerRequestor.class/instance/accessing/fileCompileRequestor.st A CodeImport.package/MethodChunkCompilerRequestor.class/instance/accessing/fileCompileRequestor_.st A CodeImport.package/MethodChunkCompilerRequestor.class/instance/accessing/interactive.st A CodeImport.package/MethodChunkCompilerRequestor.class/instance/accessing/interactive_.st A CodeImport.package/MethodChunkCompilerRequestor.class/instance/accessing/methodChunk.st A CodeImport.package/MethodChunkCompilerRequestor.class/instance/accessing/methodChunk_.st A CodeImport.package/MethodChunkCompilerRequestor.class/instance/initialization/initialize.st A CodeImport.package/MethodChunkCompilerRequestor.class/instance/interactive error protocol/notify_at_in_.st A CodeImport.package/MethodChunkCompilerRequestor.class/instance/interactive error protocol/text.st A DebuggerModel.package/DebugSession.class/instance/debugging actions/resume_.st A DebuggerModel.package/DebugSession.class/instance/private/resumeProcessWithValue_.st M Fuel.package/FLMaterializer.class/class/materializing-shortcuts/materializationFromFileNamed_.st R Nautilus-Tests.package/SortHierarchicallyTests.class/instance/private/asNodes_.st M Nautilus-Tests.package/SortHierarchicallyTests.class/instance/private/nodes_shouldBe_.st M Nautilus-Tests.package/SortHierarchicallyTests.class/instance/private/sortByNameSize_.st M Nautilus-Tests.package/SortHierarchicallyTests.class/instance/setup/setUp.st M Nautilus-Tests.package/SortHierarchicallyTests.class/instance/tests/testOneClass.st A Nautilus.package/SortHierarchically.class/class/actions/sortClasses_.st R Nautilus.package/SortHierarchically.class/class/actions/sortElements_.st R Nautilus.package/SortHierarchically.class/class/actions/sortNodes_.st M Nautilus.package/SortHierarchically.class/class/instance creation/buildHierarchyForClasses_.st M Nautilus.package/SortHierarchically.class/instance/computation/indentationFor_.st M Nautilus.package/SortHierarchically.class/instance/computation/sortedElements.st R Nautilus.package/SortHierarchicallyNode.class/README.md R Nautilus.package/SortHierarchicallyNode.class/class/instance creation/on_.st R Nautilus.package/SortHierarchicallyNode.class/definition.st R Nautilus.package/SortHierarchicallyNode.class/instance/accessing/ancestor.st R Nautilus.package/SortHierarchicallyNode.class/instance/accessing/ancestor_.st R Nautilus.package/SortHierarchicallyNode.class/instance/accessing/element.st R Nautilus.package/SortHierarchicallyNode.class/instance/computation/indent.st R Nautilus.package/SortHierarchicallyNode.class/instance/initialize-release/setElement_.st R Nautilus.package/SortHierarchicallyNode.class/instance/printing/printOn_.st M OpalCompiler-Core.package/SyntaxErrorNotification.class/definition.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50722.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50723.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50722.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50723.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tools.package/SyntaxErrorDebugger.class/class/instance creation/open_.st M Tools.package/SyntaxErrorDebugger.class/class/instance creation/syntaxError_.st M Tools.package/SyntaxErrorDebugger.class/definition.st M Tools.package/SyntaxErrorDebugger.class/instance/initialization/release.st M Tools.package/SyntaxErrorDebugger.class/instance/initialization/syntaxError_.st A Tools.package/SyntaxErrorDebugger.class/instance/menu/resume_.st A Tools.package/SyntaxErrorDebugger.class/instance/other/closeWindow.st M Tools.package/SyntaxErrorDebugger.class/instance/other/contents_notifying_.st Log Message: ----------- 50723 16961 Unable to accept changes in SyntaxErrorDebugger -> DNU: receiver of asSymbol is nil https://pharo.fogbugz.com/f/cases/16961 18111 SortHierarchically >> buildHierarchyForClasses: speedup https://pharo.fogbugz.com/f/cases/18111 18107 Failing on windows: GlobalIdentifierWithFuel>>#testBackwardCompatibility4 https://pharo.fogbugz.com/f/cases/18107 http://files.pharo.org/image/50/50723.zip

April 27, 2016