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

Re: [Pharo-dev] Happy with Pharo 5.0 release!

by stepharo

Thanks mariano But it is not out yet :) And yes this is great to see all the good energy that went into Pharo 50. Stef Le 27/4/16 Ã 16:09, Mariano Martinez Peck a Ã©crit : > 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] Command Line Arguments

by philippe.back＠highoctane.be

there should be a handler name in there. Like in pharo-ui Pharo.image st somefile.st st is the handler. as is eval or config or your own. Check subclasses of CommandLineHandler including class side. Phil On Apr 27, 2016 6:50 PM, "blake watson" <dsblakewatson(a)gmail.com> wrote: > Hi-- > > I've seen this come up several times (and it's in "Deep") but I can't seem > to actually make Command Line Arguments work. > > If I do (this is under Windows, but I set up a fresh Linux just to ensure > it wasn't a Windows quirk): > > Pharo.exe Pharo4.0image 99 > > Pharo comes up with "Command line handler failed". I see in the stack > trace that the "99" comes in as an orderedCollection. And if I do: > > Pharo.exe Pharo4.0image 99 100 101 > > I get an orderedCollection with 99, 100 and 101, which is what I'd expect. > In fact, it would be perfect if it didn't crash and put those values > somewhere, like, I don't know, CommandLineArguments' arguments variable? =) > > So, I'm obviously not getting something here. How do I make simple parm > passing work? > > Also, I note that: > > Pharo.exe 99 100 101 > > Brings up Pharo with the default image but swallows the 99, which seems > odd. I'm guessing that it looks for a 99.image and not finding it, ignores > the parameter and loads the default image. But it'd be smarter at that > point to put the 99 back, I think. > > ===Blake=== > >

April 27, 2016

Maintainer of pharo-contribution/job/PharoBookWorkInProgress CI

by Esteban A. Maringolo

Hi, Who is the maintainer of PharoBookWorkInProgress contribution job? It is failing since several builds ago, and apparently it has to do with a missing font in the LaTeX to PDF conversion. https://ci.inria.fr/pharo-contribution/job/PharoBookWorkInProgress/ Regards! Esteban A. Maringolo

April 27, 2016

Re: [Pharo-dev] [Pharo 5] Gettext

by stepharo

Hi hilaire Do you have some examples/doc/text how you do the internationalisation in DrGeo because I will start to need that? Stef Le 25/4/16 Ã 12:20, Hilaire a Ã©crit : > I open a new topic. > > It looks there are some issues with Gettext. > I saw Johan is working on it, may be he can tell us a bit more. > > The repo is here: > > MCSmalltalkhubRepository > owner: 'PharoExtras' > project: 'Gettext' > user: '' > password: '' > > Thanks > > Hilaire > > > Le 24/04/2016 21:35, stepharo a Ã©crit : >>> You can't use the installation procedure described in the wiki, because >>> Pharo5 also got stuck when loading a dependent package (gettext package >>> to name it). >> From where do you load gettext because I can have a look. >> Your work is important to me :)

April 27, 2016

Command Line Arguments

by blake watson

Hi-- I've seen this come up several times (and it's in "Deep") but I can't seem to actually make Command Line Arguments work. If I do (this is under Windows, but I set up a fresh Linux just to ensure it wasn't a Windows quirk): Pharo.exe Pharo4.0image 99 Pharo comes up with "Command line handler failed". I see in the stack trace that the "99" comes in as an orderedCollection. And if I do: Pharo.exe Pharo4.0image 99 100 101 I get an orderedCollection with 99, 100 and 101, which is what I'd expect. In fact, it would be perfect if it didn't crash and put those values somewhere, like, I don't know, CommandLineArguments' arguments variable? =) So, I'm obviously not getting something here. How do I make simple parm passing work? Also, I note that: Pharo.exe 99 100 101 Brings up Pharo with the default image but swallows the 99, which seems odd. I'm guessing that it looks for a 99.image and not finding it, ignores the parameter and loads the default image. But it'd be smarter at that point to put the 99 back, I think. ===Blake===

April 27, 2016

Re: [Pharo-dev] Logging API discussion

by Tudor Girba

Hi, > On Apr 27, 2016, at 10:43 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Denis, > >> Am 26.04.2016 um 17:28 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: >> >> Hi Tudor. >> >> 2016-04-26 15:36 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >> >> > Let's think about logging API to log any object in the system. Most natural way is just send message #log to object itself: >> > >> > anObject log >> > >> > It would be nice replacement for Object>>logCr. >> >> This type of usage should be discouraged in my opinion. We should instead encourage people to use typed logging signals, like we should also discourage people from using >> self error: âa magic string hereâ. >> >> >> > But when we log some information we usually want to log it with little remark, importance level and (most important) timestamp. This information is kind of standard for logging domain. But it requires much more methods for logging API. >> > So we need extra information to put together with objects: >> > â¢ timestamp >> > â¢ user message >> > â¢ importance level (debug, info, error, etc.) >> >> Please do not do that. This might make sense for C or Java (although it does not), but we have objects and we should filter based on those without relying on a rigid system based on random levels. Please. >> >> Before I start to think about logging I was agree with you. Now I am not. This kind of information belongs to logging domain. It can be retrieved from application objects as default values but at the end it should be explicit part of log entries. We can read it in logs for every record to realize when and why object was added to log, what this record is about. >> >> And you say let's replace this "log object context" information with first class entities "typed signals". It means that for any possible case when I want to put something in log I should create class for new signal. It's just not practical. >> Beacon introduce WrapperSignal to solve it. But it only provides target and timestamp. What I should do if I want to put little remark for my object? And what if I want to put little remark for ThisContextSignal? >> >> My idea that logging should be as simple as possible and we not need another "everything is signal" concept here: it is restriction. Everything is object. And every object should be able to log. >> >> And about random log levels. Their purpose is to mark log entries with importance level which is useful to explore logs. >> Imaging we have system which produce some events and we log them. (My and your approaches allow it. Only difference that in my approach this event will be part of log entry (as composition) and with your approach this event will be log entry itself). >> Now imagine that we need to explore some problem situation when particular events are appeared but they should not. I would try to find wrong places in code where events can be signalled and I would log them their. >> With my approach I will log them with specific importance level (#warning) and specific message to distinguish them from normal events. With my API it is super easy. >> With your approach I will need to create new classes to signal this situation. >> Also my approach allows me to configure in advance my application to put warnings in separate log. So I will not need to change app configs to simplify experiment. I will just deploy new code with extra logging and wait results in ready to use log. >> >> My proposals are not opposite to your. I just not put extra restrictions. Beacon can be based on top of it but not vice versa. > > 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. Yes. > 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 is a good point. I still see it closer to the event than to the logger. > 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. Yes. I think it would be worthwhile to think about a composition mechanism. We could potentially use decorators for capturing extra information in the log event 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. I agree that we would benefit from an instance-based filtering mechanism, but I do not see why this is harder in Announcement. However we do it, it can be added to Announcements and it is available for all purposes (not just logging). Maybe I am missing something. > 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. Nowadays I think you should be able to use any object as log object. The provided classes are just helpers. A composed object that has timestamp, level and a message object is a good utility but not a requirement. We need to support all of these. And so I would object against putting a lot of protocol in the Object class. In SystemLogger you have > > Object>>#asLog > ^ self class newLog message: self One thing that I think is misleading (I remember it took me some minutes to wrap my head around it) is the way SystemLogger uses the term âlogâ. In English, log denotes all entries (a log book), but in SystemLogger it is used to denote one event. In any case, having an as* pattern (like it exists in Beacon) is the way to go. > Object class>>#newLog > ^ self logClass new > > Object class>>#logClass > "Hook supporting the redefinition by object of their associated log. > When using myObject asLog emit, the logClass will be used and myObject will be passed as message argument." > > ^ Log This is another thing that is different from Beacon. I see the logging as a description of an event that is worthwhile capturing. This event has a strategy to record things. For example, when you capture an exception you might want to capture the complete context including the sender objects, or just the methods from the stack. This decision is tied to the Exception, but depends on the logging place. That is why I think we should not invest much in the pattern of hardcoding the strategy with the object. So, from this point of view, I would not want to pursue #logClass. > 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. Yes. > So to me the discussion about Log classes is not very helpful. We can have dedicated log classes like the stack capturing one but also one that is composed of the message object and certain qualities. If you would have a WrappedSyslogSignal you can have a log object that is composed and syslog aware by providing log levels. I would actually like to invest in building a composition mechanism. This would allow us to compose logging objects with the information we would like to have. > Again I think the hard part is to have flexible logging and still be able to filter it. I would like to be able to attach a handful of loggers and be sure the loggers get the right set of log objects they are interested in. Do you have a concrete set of examples that you would like to see working? I think it would be useful to have a set of these concrete use cases to catch different design decisions against them. I have some cases and I will try to summarize them, but after the release of Pharo. Cheers, Doru > Norbert > > > > > -- www.tudorgirba.com www.feenk.com "If you can't say why something is relevant, it probably isn't."

April 27, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50724 Home: https://github.com/pharo-project/pharo-core

April 27, 2016

[pharo-project/pharo-core] 6abd66: 50724

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 6abd6627cf05cd6b0c99d71e58100a8763fcd309 https://github.com/pharo-project/pharo-core/commit/6abd6627cf05cd6b0c99d71e… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-04-27 (Wed, 27 Apr 2016) Changed paths: A ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/versions/v0%5F19%5F2_.st M Komitter.package/KomitDefinition.class/class/instance creation/definition_.st M Komitter.package/KomitMethod.class/class/instance creation/method_.st M Komitter.package/KomitPackage.class/class/instance creation/package_.st A Komitter.package/KomitPackage.class/instance/accesing/classNamed_.st M Komitter.package/KomitPackage.class/instance/protocol/classes.st M Komitter.package/KomitStagingArea.class/class/instance creation/currentFilteredBy_.st M Komitter.package/KomitStagingArea.class/definition.st A Komitter.package/KomitStagingArea.class/instance/accessing/flush.st A Komitter.package/KomitStagingArea.class/instance/accessing/initializePackages.st M Komitter.package/KomitStagingArea.class/instance/accessing/packages.st A Komitter.package/KomitStagingArea.class/instance/adding%2Fremoving/filterBlock.st A Komitter.package/KomitStagingArea.class/instance/adding%2Fremoving/filterBlock_.st R Komitter.package/KomitStagingArea.class/instance/initialize/initialize.st M Komitter.package/KomitStagingArea.class/instance/protocol/remotes.st M Komitter.package/Komitter.class/instance/announcement/classModified_.st M Komitter.package/Komitter.class/instance/announcement/classMoved_.st M Komitter.package/Komitter.class/instance/announcement/classRemoved_.st M Komitter.package/Komitter.class/instance/announcement/mcPackageModified_.st M Komitter.package/Komitter.class/instance/announcement/methodModified_.st M Komitter.package/Komitter.class/instance/announcement/methodMoved_.st R Komitter.package/Komitter.class/instance/announcement/methodRemoved_.st M Komitter.package/Komitter.class/instance/announcement/registerToAnnouncements.st M Komitter.package/Komitter.class/instance/initialize/initialize.st A Komitter.package/Komitter.class/instance/rebuilding/rebuildStagingArea.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50723.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50724.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50723.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50724.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M UnifiedFFI.package/FFICallout.class/class/class initialization/initializeTypeAliases.st M UnifiedFFI.package/FFICalloutAPI.class/instance/action/function_module_.st M UnifiedFFI.package/extension/ExternalAddress/class/fromString_.st Log Message: ----------- 50724 18061 Komitter is referring to old versions https://pharo.fogbugz.com/f/cases/18061 17963 FFICalloutAPI class ignores context instance variable https://pharo.fogbugz.com/f/cases/17963 http://files.pharo.org/image/50/50724.zip

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 16:15, philippe.back(a)highoctane.be <philippe.back(a)gmail.com> wrote: > > Will do the CentOS 6 thing. > I replicated the jobs that were creating centos vms (I think thatâs for 6)â¦ if you can try those, it would be cool :) Esteban > 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 <mailto:estebanlm@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 <http://pharo.org/download-50> > > and one for linux: > > http://pharo.org/gnu-linux-installation-50 <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] [HELP WANTED] Pre-release "First impressions count" round starting

by Hilaire

I guess you can look at my notes I sent previously. It belongs to "First impressions count" category. Hilaire Le 19/04/2016 15:25, Esteban Lorenzano a Ã©crit : > I will start the âfirst impressions countâ round for this release. > For those who donât know what Iâm talking about, is a small cycle of improvements onâ¦ well, âfirst impressionsâ a newbie will have when downloading Pharo for a first time. -- Dr. Geo http://drgeo.eu

April 27, 2016