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

[Hilaire]

Here are the overall process

http://pharo.gemtalksystems.com/book/LanguageAndLibraries/Localisation

For Dr. Geo I have bit more to decide which font to load at start up
depending on the locale (This is where Pharo5's locale refactoring break
it) but you should not need it for European languages.

Hilaire
-- 
Dr. Geo
http://drgeo.eu

[Pharo-dev] [pharo-project/pharo-core] 691635: 50726

[GitHub]

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 6916359c22b2bb246ac14e94ca25c2275b6e027e
  
https://github.com/pharo-project/pharo-core/commit/6916359c22b2bb246ac14e94ca25c2275b6e027e
  Author: Jenkins Build Server 
  Date:   2016-04-28 (Thu, 28 Apr 2016)

  Changed paths:
M 
ConfigurationOfQualityAssistant.package/ConfigurationOfQualityAssistant.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfQualityAssistant.package/ConfigurationOfQualityAssistant.class/instance/versions/v2%5F6%5F6_.st
M QualityAssistant.package/QANautilusPlugin.class/definition.st
M QualityAssistant.package/QANautilusPlugin.class/instance/announcement 
handling/updateMorph.st
R 
QualityAssistant.package/QANautilusPlugin.class/instance/initialization/initialize.st
R 
QualityAssistant.package/QANautilusPluginMorph.class/class/private/startPrivacyPromptTaskIfNecessary.st
M QualityAssistant.package/QANautilusPluginMorph.class/definition.st
M 
QualityAssistant.package/QANautilusPluginMorph.class/instance/actions/updateList.st
M 
QualityAssistant.package/QANautilusPluginMorph.class/instance/initialization/initialize.st
M 
QualityAssistant.package/QANautilusPluginMorph.class/instance/initialization/privacyMorph.st
M QualityAssistant.package/QANautilusPluginMorph.class/instance/task 
handling/excecuteTask.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50725.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50726.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50725.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50726.st
M 
ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  50726
18115 QA v2.6.6
https://pharo.fogbugz.com/f/cases/18115

http://files.pharo.org/image/50/50726.zip

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] ac14c7: 50725

[GitHub]

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: ac14c752c7e6bc68792f0363fce68a423682bb8d
  
https://github.com/pharo-project/pharo-core/commit/ac14c752c7e6bc68792f0363fce68a423682bb8d
  Author: Jenkins Build Server 
  Date:   2016-04-28 (Thu, 28 Apr 2016)

  Changed paths:
M 
ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version312_.st
M 
ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version210_.st
M 
ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/symbolic
 versions/stable_.st
M 
ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version321_.st
M 
GT-Spotter.package/GTSpotterExtensionSettings.class/class/private/doesNotUnderstand_.st
M 
GT-Spotter.package/GTSpotterExtensionSettings.class/class/settings/catalogSettingsOn_.st
R GT-Tests-Inspector.package/GTInspectorDummyExamplesTest.class/README.md
R 
GT-Tests-Inspector.package/GTInspectorDummyExamplesTest.class/definition.st
R 
GT-Tests-Inspector.package/GTInspectorDummyExamplesTest.class/instance/accessing/allExamplesDummiesProviders.st
R 
GT-Tests-Inspector.package/GTInspectorDummyExamplesTest.class/instance/accessing/invalidExamplesDummiesProviders.st
R 
GT-Tests-Inspector.package/GTInspectorDummyExamplesTest.class/instance/accessing/recursiveExamplesDummiesProviders.st
R 
GT-Tests-Inspector.package/GTInspectorDummyExamplesTest.class/instance/tests/testExists.st
R 
GT-Tests-Inspector.package/GTInspectorDummyExamplesTest.class/instance/tests/testInvalidDefinitions.st
R 
GT-Tests-Inspector.package/GTInspectorDummyExamplesTest.class/instance/tests/testIsEquals.st
R 
GT-Tests-Inspector.package/GTInspectorDummyExamplesTest.class/instance/tests/testIsGTExample.st
R 
GT-Tests-Inspector.package/GTInspectorDummyExamplesTest.class/instance/tests/testMatchesMethod.st
R 
GT-Tests-Inspector.package/GTInspectorDummyExamplesTest.class/instance/tests/testRecursiveDefinitions.st
R 
GT-Tests-Inspector.package/GTInspectorDummyExamplesTest.class/instance/tests/testResult.st
R 
GT-Tests-Inspector.package/GTInspectorDummyExamplesTest.class/instance/tests/testRun.st
R 
GT-Tests-Inspector.package/GTInspectorDummyExamplesTest.class/instance/utils/examplesInClasses_do_.st
M GT-Tests-Inspector.package/GTInspectorExamplesManualTest.class/README.md
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50724.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50725.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50724.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50725.st
M 
ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  50725
Moose

http://files.pharo.org/image/50/50725.zip

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

[Pharo-dev] STON - a little suggestion

[Carlos Lombardi]

Hi,

I want to use STON to enable the backup a graph of objects pertaining to an
application.
Some of the objects in this graph include, in their state, a Map that is
not supported by STON.
To write these objects, I would like to write via the standard procedure
all the instance variables unless that pointing to such a map, and then add
a modified version of that map by hand.

To exclude the conflicting variable is easy, I just redefine
#stonAllInstVarNames at the class side as follows:
 ^self instVarNames reject: [ :theName | (theName = #references) ]
in this way, I do not need to modify the method if the state of these
objects changes.
On the other hand, I found not easy to use the standard mechanism for the
included instance variables. This mechanism is embedded in
STONWriter>>writeObject: . I found no option but repeat the logic codified
there, in the method #stonOn: of my class.

The easiest way to let STON integrate the standard mechanism to store the
state of an object, with by-hand additions, is to slightly modify
STONWriter>>writeObject:, adding just one line. Objects including instance
variables would be written as follows:

self writeObject: anObject streamMap: [ :dictionary |
instanceVariableNames do: [ :each |
(anObject instVarNamed: each)
ifNotNil: [ :value |
dictionary at: each asSymbol put: value ]
ifNil: [
anObject stonShouldWriteNilInstVars
ifTrue: [ dictionary at: each asSymbol put: nil ] ] ] .
anObject stonAdditionalInfoOn: dictionary . ]

the added line is the last one, the invocation to #stonAdditionalInfoOn:.
Of course, the method #stonAdditionalInfoOn: should be added to the Object
class.
By redefining this method in my class, I was able to easily add the
modified, STON-compatlble value, to the values handled by the STON code.

I did not need to modify the STON code to read the STON String to generate
a new object.

Do you think that doing this modification to STON could be a good idea?

Cordially - Carlos


PS: I envisaged as an alternative, to allow the following method in my class

stonOn:stonWriter
stonWriter writeObjectAsMap: self
  do: [:mapWriter |
   // added code goes here
   stonWriter writeInstVarsOf: self on: mapWriter
   // added code goes here
  ]

To this end, the methods #writeObjectAsMap:do: and #writeInstVarsOf:on
should be added to STONWriter. The method
 writeInstVar: aSymbol  of: anObject  on: mapWriter
could be offered as well, to allow more fine-grained redefinitions of
stonOn: , while keeping the ability to use the standard mechanism to store
an instance variable.

I think that the option I described earlier is simpler, I include this one
because maybe other people would prefere it.

Re: [Pharo-dev] Command Line Arguments

[Cyril Ferlicot D.]

Le 27/04/2016 22:51, blake watson a écrit :
> Phil, Estevan--
> 
> I think part of what confused me is that there's no printout at all
> under Windows, so Pharo opens and says "Yep, that worked." But there's
> no actual output anywhere.

Hi,

This is because stdin/stdout/stderr stream does not work on windows :(
There might be a "stderr" file close to your image with the output.

> 
>>>ps: this questions are more for the pharo-users list than pharo-dev :)
> 
> Duly noted. For some reason, I thought that was defunct. (But I had just
> unsubscribed somehow.)
> 
> 

-- 
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] Mocketry names again

[Carlos Lombardi]

Hi again,

ok, just to have coherence between the names for the two possible outcomes
of a method, you could use #beReturnedBy instead of #beReturnedFrom: . You
would have #beReturnedBy:  and  #beRaisedBy:

On Wed, Apr 27, 2016 at 10:00 AM, Denis Kudriashov 
wrote:

>
> 2016-04-27 0:33 GMT+02:00 Carlos Lombardi :
>
>> ... maybe
>>
>> #result should beTheResultOf: [mock someMessage].
>> #result should not beTheResultOf: [mock anotherMessage].
>>
>
> It's nice.I think "The" can be omitted:
>
> #result should beResultOf: [mock someMessage].
>
>
> But anyway I use word #return because there are different types of result:
> value return and error signal. There is no expression for last case but it
> would be like:
>
> anError should beRaisedBy: [mock someMessage]
>
>

Re: [Pharo-dev] Command Line Arguments

[blake watson]

Phil, Estevan--

I think part of what confused me is that there's no printout at all under
Windows, so Pharo opens and says "Yep, that worked." But there's no actual
output anywhere.

>>ps: this questions are more for the pharo-users list than pharo-dev :)

Duly noted. For some reason, I thought that was defunct. (But I had just
unsubscribed somehow.)


On Wed, Apr 27, 2016 at 11:53 AM, Esteban Lorenzano 
wrote:

> pharo Pharo.image  --list
>
> will give you the command lines available, then
>
> pharo Pharo.image  aCommand --help
>
> will give you the subcommands possible
>
> in your case, you want something like this:
>
> pharo Pharo.image eval “99 factorial”
>
> cheers,
> Esteban
>
> ps: this questions are more for the pharo-users list than pharo-dev :)
>
> On 27 Apr 2016, at 20:04, philippe.b...@highoctane.be <
> philippe.b...@gmail.com> wrote:
>
> 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"  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===
>>
>>
>

Re: [Pharo-dev] About PharoInProgress book

[Esteban A. Maringolo]

I sent an email this morning about this issue, apparently it has to do
with a missing font.

Esteban A. Maringolo


2016-04-27 16:50 GMT-03:00 stepharo :
> Hi
>
> I tried to fix the build on jenkins but I failed. I do not know how to fix
> it.
>
> I do not know how to fix. Probably the changes in Pillar broke it.
>
> Now since Damien will quit our team, I wonder what will be the future of
> pillar, may be markdown and for me LaTeX
>
> Stef
>
>
>
> ./AWS.tex:40: LaTeX Error: Environment listing undefined.
>
> See the LaTeX manual or LaTeX Companion for explanation.
> Type  H   for immediate help.
> ...
>
> l.40 \begin{listing}
>  [language=smalltalk]
> Your command was ignored.
> Type  Ito replace it with another command,
> orto continue without it.
>
>
> ./AWS.tex:53: LaTeX Error: \begin{document} ended by \end{listing}.
>
> See the LaTeX manual or LaTeX Companion for explanation.
> Type  H   for immediate help.
> ...
>
> l.53 \end{listing}
>
> Your command was ignored.
> Type  Ito replace it with another command,
> orto continue without it.
>
> No file AWS.bbl.
>
>

[Pharo-dev] About PharoInProgress book

[stepharo]

Hi

I tried to fix the build on jenkins but I failed. I do not know how to 
fix it.


I do not know how to fix. Probably the changes in Pillar broke it.

Now since Damien will quit our team, I wonder what will be the future of 
pillar, may be markdown and for me LaTeX


Stef



./AWS.tex:40: LaTeX Error: Environment listing undefined.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H   for immediate help.
...

l.40 \begin{listing}
 [language=smalltalk]
Your command was ignored.
Type  Ito replace it with another command,
orto continue without it.


./AWS.tex:53: LaTeX Error: \begin{document} ended by \end{listing}.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H   for immediate help.
...

l.53 \end{listing}

Your command was ignored.
Type  Ito replace it with another command,
orto continue without it.

No file AWS.bbl.

Re: [Pharo-dev] Logging API discussion

[stepharo]

Le 27/4/16 à 14:16, Denis Kudriashov a écrit :
2016-04-27 10:43 GMT+02:00 Norbert Hartl >:


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.


not necessary
we could have Log being a potential wrapper.

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

Re: [Pharo-dev] Logging API discussion

[stepharo]

Le 27/4/16 à 13:01, Denis Kudriashov a écrit :

Hi Norbert

2016-04-27 10:43 GMT+02:00 Norbert Hartl >:


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.

Denis I do not get what you mean with the sentence above.

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.

Re: [Pharo-dev] Logging API discussion

[stepharo]

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. 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. 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

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

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.


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. 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.



Hi norbert

I agree.
I have the impression that in SystemLogger I would change message: into 
object: in Log and remove all the extension API I tried to design.
This way people can just pass the object they want if they want still to 
have the object wrapped into a Log instances.
I think that Log instances and subclasses would be nice to have specific 
behavior (like menu actions when we want to manipulate logs).


For example, I would like to have a tool looging all the methods that I 
did not define during a prototype session and after I can click on them 
and say "define skeleton"
and boum I get a skeleton for all the methods inside their respective 
classes.


Stef

Re: [Pharo-dev] Command Line Arguments

[Esteban Lorenzano]

pharo Pharo.image  --list 

will give you the command lines available, then 

pharo Pharo.image  aCommand --help 

will give you the subcommands possible

in your case, you want something like this: 

pharo Pharo.image eval “99 factorial”

cheers, 
Esteban

ps: this questions are more for the pharo-users list than pharo-dev :)

> On 27 Apr 2016, at 20:04, philippe.b...@highoctane.be 
>  wrote:
> 
> 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"  > 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===
> 

Re: [Pharo-dev] Logging API discussion

[stepharo]

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.


But denis why this is not for a certain kind of subclass
You have Log with the minimal information (timestamp and an object)
then you can have logger with levels and other.


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.

why?
MySpecialLog
...
emit

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.


In the minimalLog

MinimalLog
object: MyCoolObject new;
emit

no need of message



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.

Re: [Pharo-dev] Logging API discussion

[stepharo]

what I can tell you is that I do not like the API I did for extending 
Log in SystemLogger.


I will try to read your long email.

Now I have the impression that wrapping an object in the log could be a 
way to offer extensibility.



Le 26/4/16 à 15:26, Denis Kudriashov a écrit :

Hello.

I resumed discussion about SystemLogger and Beacon here 
http://forum.world.st/What-the-state-of-unifying-Beacon-with-SystemLogger-td4890684.html. 

I plan to unify both approaches by saving traditional terminology from 
SystemLogger and cool features from Beacon.


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.
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:

 1. timestamp
 2. user message
 3. importance level (debug, info, error, etc.)
 4. whatever (process hash, process name for example)
 5. sometimes it can be needed to put in log something different than
object itself. (for example it can be just copy of object to not
change state of log entry during app lifetime)

Here is possible API based on Object extensions. It has drawbacks but 
it is good to think about it too:


"it will put anObject in logs with default #info level"

anObject log

"it will put anObject in logs with default #info level and given
user message"
anObject logWith: 'something interesting was happened with anObject'

 "inside block we can put any logging domain information from
application and also override content by specific representation"
anObject logBy: [:logEntry |

  logEntry message: 'something interesting to be saved with
our object'

  logEntry content: anotherObject] "here logs with interest
about anObject will receive logEntry with anotherObject instead of
anObject"


And similar for different kind of levels:

anObject logForDebug.
anObject logForDebugWith: 'some debug message'
anObject logForDebugBy: [:logEntry | ]


anObject logAsError.
anObject logAsError: 'object computation was wrong'
anObject logAsErrorBy: [:logEntry | ]

And most general:

anObject logAs: LogLevel warn

anObject logAs: LogLevel warn with:  'something interesting'
anObject logAs: LogLevel warn by: [:logEntry | ]


And in case of classic logging with strings only first expressions 
would be used:


'some info message' log.
'some debug message' logForDebug
'some error message' logAsError
'some warn message' logAs: LogLevel warn

Problem with this approach: it pollutes Object with 12 extra methods 
and it can be more. So maybe it is better to use current SystemLogger 
API based on class Log:


Log info: anObject
Log info: anObject as: 'computation result'  "as example"
Log info: anObject as: [:logEntry |

logEntry message: 'something interesting to be saved with our
object

logEntry content: anotherObject]


Log error: anObject

Log error: anObject as: 'computation was wrong''

Log error: anObject as: [:logEntry | ]


Comparing to original SystemLogger versions I separate user message 
from object content. It makes possible to log any object with extra 
user message.
But anyway it not feels very well IMHO. And it requires three methods 
for each log level. Maybe we can put this methods into LogLevel itself:


Log info add: anObject
Log info add: anObject as: 'computation result'
Log info add: anObject as: [:logEntry |

logEntry message: 'something interesting to be saved with our
object

logEntry content: anotherObject]


Log error add: anObject

Log error add: anObject as: 'computation was wrong''

Log error add: anObject as: [:logEntry | ]


And we can make short version for default logging level (which can be 
object specific):



Log add: anObject

Log add: anObject as: 'computation result'

Log add: anObject as: [:logEntry | ]


That's all. I hope we can produce best suitable API for object 
logging. Then we can think how to adopt SystemLogger or Beacon for it.
Also think about this API in context that we can register specific 
loggers for specific objects and specific importance level.


Best regards,
Denis

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

[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

Re: [Pharo-dev] Command Line Arguments

[philippe.b...@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"  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===
>
>

[Pharo-dev] Maintainer of pharo-contribution/job/PharoBookWorkInProgress CI

[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

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

[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 :)

[Pharo-dev] Command Line Arguments

[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===

Re: [Pharo-dev] Logging API discussion

[Tudor Girba]

Hi,



> On Apr 27, 2016, at 10:43 AM, Norbert Hartl  wrote:
> 
> Denis,
> 
>> Am 26.04.2016 um 17:28 schrieb Denis Kudriashov :
>> 
>> Hi Tudor.
>> 
>> 2016-04-26 15:36 GMT+02:00 Tudor Girba :
>> 
>> > 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 wou

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

[GitHub]

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 6abd6627cf05cd6b0c99d71e58100a8763fcd309
  
https://github.com/pharo-project/pharo-core/commit/6abd6627cf05cd6b0c99d71e58100a8763fcd309
  Author: Jenkins Build Server 
  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

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

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

[Esteban Lorenzano]

> On 27 Apr 2016, at 16:15, philippe.b...@highoctane.be 
>  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"  > 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
> 
> 

Re: [Pharo-dev] [HELP WANTED] Pre-release "First impressions count" round starting

[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

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

[philippe.b...@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"  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
>
>
>

[Pharo-dev] Happy with Pharo 5.0 release!

[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

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

[Esteban Lorenzano]

> On 27 Apr 2016, at 15:31, Damien Cassou  wrote:
> 
> Esteban Lorenzano  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

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

[Damien Cassou]

Esteban Lorenzano  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

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

[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

Re: [Pharo-dev] Logging API discussion

[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 >:


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
.  ..   ...^,^

Re: [Pharo-dev] Logging API discussion

[Denis Kudriashov]

2016-04-27 14:16 GMT+02:00 Denis Kudriashov :

> 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

Re: [Pharo-dev] Logging API discussion

[Denis Kudriashov]

2016-04-27 10:43 GMT+02:00 Norbert Hartl :

> 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

Re: [Pharo-dev] Logging API discussion

[Denis Kudriashov]

Hi Norbert

2016-04-27 10:43 GMT+02:00 Norbert Hartl :

> 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.

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

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

[GitHub]

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 2a4187f4040254cb31d2fc7b5f2f4158a9a296e1
  
https://github.com/pharo-project/pharo-core/commit/2a4187f4040254cb31d2fc7b5f2f4158a9a296e1
  Author: Jenkins Build Server 
  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

Re: [Pharo-dev] Logging API discussion

[Norbert Hartl]

Denis,

> Am 26.04.2016 um 17:28 schrieb Denis Kudriashov :
> 
> Hi Tudor.
> 
> 2016-04-26 15:36 GMT+02:00 Tudor Girba  >:
> 
> > 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. 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. 
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 uti

Re: [Pharo-dev] XMLParser changes

[Cyril Ferlicot Delbecque]

On 27/04/2016 09:12, stepharo wrote:
> Hi guys
> 
> 
> I did not understand where are the spaces?
> 

The whitespaces are the line return and tabulation (indent) for the
pretty print.

> Can you show me?
> 
> Stef
> 

-- 
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] Mocketry names again

[Denis Kudriashov]

2016-04-27 0:33 GMT+02:00 Carlos Lombardi :

> ... maybe
>
> #result should beTheResultOf: [mock someMessage].
> #result should not beTheResultOf: [mock anotherMessage].
>

It's nice.I think "The" can be omitted:

#result should beResultOf: [mock someMessage].


But anyway I use word #return because there are different types of result:
value return and error signal. There is no expression for last case but it
would be like:

anError should beRaisedBy: [mock someMessage]

Re: [Pharo-dev] XMLParser changes

[Norbert Hartl]

Stef,

if you have

foo

and then you indent it


foo


you insert after  a newline and spaces or tabs as well as after . In 
this case the whitespace between  and  is valid but ignorable. 

Norbert

> Am 27.04.2016 um 09:12 schrieb stepharo :
> 
> Hi guys
> 
> 
> I did not understand where are the spaces?
> 
> Can you show me?
> 
> Stef
> 
> 
 (XMLDOMParser parse: '
 
 
 
 
 
 
 
 
 
 
 ') elements first nodes
 
 With the release 2.7.4 we get 2 nodes but in release 2.7.6 we get 5
 nodes. The 2 previous ones and 3 empty String nodes.
 
 I think this is not what we expect. Correct me if I am wrong :)
 
 
>>> 
>> 
> 
> 

Re: [Pharo-dev] XMLParser changes

[stepharo]

Hi guys


I did not understand where are the spaces?

Can you show me?

Stef



(XMLDOMParser parse: '


 
 
 
 
 
 
 
 
') elements first nodes

With the release 2.7.4 we get 2 nodes but in release 2.7.6 we get 5
nodes. The 2 previous ones and 3 empty String nodes.

I think this is not what we expect. Correct me if I am wrong :)