Re: [Pharo-dev] FileDoesNotExist vs. FileDoesNotExistException

[Francisco Ortiz Peñaloza]

I do prefer the shorter name. Generally I avoid using exception as a suffix
consistently if doesn't add information.

Consistency is overrated :D

On Thursday, 8 September 2016, Esteban Lorenzano 
wrote:

>
> > On 08 Sep 2016, at 09:03, Guille Polito  > wrote:
> >
> > I'd argue also for consistency. When some exceptions are named
> "Exception" and others are not, my eyes hurt.
>
> +1
>
> >
> >  Original Message 
> >> My very first thoughts are...
> >>
> >> On Thu, Sep 8, 2016 at 3:35 AM, stepharo  > wrote:
> >>> Hi guys
> >>>
> >>> in
> >>> https://pharo.fogbugz.com/f/cases/19026/Merge-FileDoesNotExist-and-
> FileDoesNotExistException
> >>> sven proposed to have
> >>>
> >>> FileDoesNotExist and remove the FileDoesNotExistException
> >> This seems quite reasonable.  It would be very hard to confuse the
> >> semantics of FileDoesNotExist with something else.  Also this is
> >> probably something end-user-devs will use more frequently in their
> >> application, so less verbose is better.
> >>
> >> The only thing that crosses my mind is perhaps discoverability... in
> >> Spotter searching on "File" the drilling into classes and searching on
> >> "Exception".Oh I just tried in Pharo 5 and it worked, there are
> >> four.   The other way to handle that might be for Spotter to have a
> >> "KindOf" search.
> >>
> >> btw, in the Spotter preview pane when a class is selected, could the
> >> class comment be displayed?
> >>
> >>> Before doing it I would like to have your point of view on the names.
> For
> >>> now I'm neutral and indeed if we apply it to exception
> >>>
> >>> it seems to work for announcement. Now in Spec I was planning to put
> nearly
> >>> systematically Presenter at the end of Presenters :).
> >> Spec has more interrelated design pattern components.  Its seems there
> >> has been some confusion around the nomenclature of these components.
> >> So the additional hint is probably beneficial.
> >>
> >> cheers -ben
> >>
> >
> >
>
>
>

Re: [Pharo-dev] Cycles lost on startup

[Nicolai Hess]

2016-09-06 12:34 GMT+02:00 Eliot Miranda :

>
>
> On Sep 6, 2016, at 12:25 PM, Nicolai Hess  wrote:
>
>
>
> 2016-09-06 11:47 GMT+02:00 Henrik Nergaard :
>
>> Rewriting the implementation of #initSelectorTable to:
>>
>>
>>
>> SelectorTable := WeakSet withAll: (CompiledMethod allInstances collect:
>> [:m | m selector] as: IdentitySet).
>>
>>
>>
>> Makes it 20ms faster, so it looks like there is some overhead when using
>> WeakSet compared to first use a normal set to remove duplicates.
>>
>>
>>
>> Another possibility could be to store the selectors in an
>> IdentityDictionary as #selector->count which keep track of how many users
>> of a selector there is itself, instead of using a WeakArray.
>>
>>
>>
>> Best regards,
>>
>> Henrik
>>
>
> Maybe we can just move the rebuilding to the image shutdown instead of the
> image startup ?
>
>
> That's a much better idea.  But only if the image snapshots.  There is no
> point doing it on an exit without saving.
>

Is there a way to see whether we are just quitting or "quit & save" in
Pharos Session/Shutdown list "shutDown:" method ?


>
> And just to drive home the point, 70ms is an age in a web server.  This
> kind of thing really damages Pharo performance in web servers.  One wants
> startup times in the few tens of milliseconds or better.
>
>
>
>
>>
>>
>> *From:* Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] *On Behalf
>> Of *Nicolai Hess
>> *Sent:* Monday, September 5, 2016 7:52 PM
>> *To:* Pharo Development List 
>> *Subject:* Re: [Pharo-dev] Cycles lost on startup
>>
>>
>>
>>
>>
>>
>>
>> 2016-09-05 18:37 GMT+02:00 Eliot Miranda :
>>
>> Hi All,
>>
>>
>>
>> we are simulating a full block Pharo image derived from Pharo 6.  On
>> startup we see a very sad loss of cycles due to a very slow rebuild of the
>> selector table in Symbol class.  Why is this done at each startup?  Here is
>> the stack:
>>
>>
>>
>>   16r107154 M ByteString class(ProtoObject)>identityHash 16r786AE8: a(n)
>> ByteString class
>>
>>   16r10716C M ByteString class(Object)>hash 16r786AE8: a(n) ByteString
>> class
>>
>>   16r10718C M ByteSymbol(String)>hash 16rE6A5C8: a(n) ByteSymbol
>>
>>   16r1071B0 M WeakSet>scanForEmptySlotFor: 16r26B968: a(n) WeakSet
>>
>>   16r1071DC M WeakSet>noCheckNoGrowFillFrom: 16r26B968: a(n) WeakSet
>>
>>   16r1071FC M WeakSet>growTo: 16r26B968: a(n) WeakSet
>>
>>   16r10721C M WeakSet>grow 16r26B968: a(n) WeakSet
>>
>>   16r107234 M WeakSet(HashedCollection)>fullCheck 16r26B968: a(n) WeakSet
>>
>>   16r10724C M WeakSet(HashedCollection)>atNewIndex:put: 16r26B968: a(n)
>> WeakSet
>>
>>   16r107274 M WeakSet>add: 16r26B968: a(n) WeakSet
>>
>>   16r107294 M [] in Symbol class>(nil) 16r1D319A8: a(n) Symbol class
>>
>>   16r1072B8 M Array(SequenceableCollection)>do: 16r3C17370: a(n) Array
>>
>>   16r1072E8 I CompiledMethod class(Behavior)>allInstancesDo: 16r164E260:
>> a(n) CompiledMethod class
>>
>>   16r10730C I Symbol class>initSelectorTable 16r1D319A8: a(n) Symbol class
>>
>>   16r10732C I Symbol class>selectorTable 16r1D319A8: a(n) Symbol class
>>
>>   16r107350 I Symbol class>internSelector: 16r1D319A8: a(n) Symbol class
>>
>>   16r10737C I CompiledMethod>selector: 16r26AB58: a(n) CompiledMethod
>>
>>   16r1073A4 I IRMethod>generate: 16r25A030: a(n) IRMethod
>>
>>   16r1073CC I FFICalloutMethodBuilder>generateMethodFromSpec: 16r255580:
>> a(n) FFICalloutMethodBuilder
>>
>>   16r1073F0 I FFICalloutMethodBuilder>generate 16r255580: a(n)
>> FFICalloutMethodBuilder
>>
>>   16r1030C8 I FFICalloutMethodBuilder>build: 16r255580: a(n)
>> FFICalloutMethodBuilder
>>
>>   16r1030F4 I FFICalloutAPI>function:module: 16r255568: a(n) FFICalloutAPI
>>
>>   16r10311C I UnixEnvironment(Object)>ffiCall:module: 16r3816180: a(n)
>> UnixEnvironment
>>
>>   16r103144 I UnixEnvironment(OSEnvironment)>getEnv: 16r3816180: a(n)
>> UnixEnvironment
>>
>>   16r103168 I UnixEnvironment(OSEnvironment)>at:ifAbsent: 16r3816180:
>> a(n) UnixEnvironment
>>
>>   16r10318C M [] in MacOSResolver>(nil) 16r241170: a(n) MacOSResolver
>>
>>   16r1031A4 M FullBlockClosure(BlockClosure)>on:do: 16r2553F0: a(n)
>> FullBlockClosure
>>
>>   16r1031D0 I MacOSResolver(PlatformResolver
>> )>directoryFromEnvVariableNamed:or: 16r241170: a(n) MacOSResolver
>>
>>   16r1031F8 I MacOSResolver(PlatformResolver
>> )>directoryFromEnvVariableNamed: 16r241170: a(n) MacOSResolver
>>
>>   16r10321C I MacOSResolver>home 16r241170: a(n) MacOSResolver
>>
>>   16r10323C I MacOSResolver>userLibrary 16r241170: a(n) MacOSResolver
>>
>>   16r103254 M MacOSResolver>userApplicationSupport 16r241170: a(n)
>> MacOSResolver
>>
>>   16r10326C M MacOSResolver(FileSystemResolver)>resolve: 16r241170: a(n)
>> MacOSResolver
>>
>>   16r103288 M SystemResolver(FileSystemResolver)>unknownOrigin:
>> 16r240D30: a(n) SystemResolver
>>
>>   16r1032A4 M SystemResolver(FileSystemResolver)>resolve: 16r240D30:
>> a(n) 

[Pharo-dev] Latest Configuration of XPath is broken

[Henrik Nergaard]

Hi,

Trying to load XPath using the latest configuration 
(ConfigurationOfXPath-monty.91) gives the following error:
MetacelloProjectSpecLoadError: No version found for #'release-2.8.7' of 
ConfigurationOfXMLParser because: The symbolic version #'release-2.8.7' is not 
defined in ConfigurationOfXMLParser for the current platform. Possible symbolic 
version values include: #(#bleedingEdge #development #'release-2' 
#'release-2.4' #'release-2.5' #'release-2.5.3' #'release-2.5.5' #'release-2.6' 
#'release-2.6.3' #'release-2.6.5' #'release-2.6.8' #'release-2.7.3' 
#'release-2.7.4' #'release-2.7.6' #'release-2.7.7' #'release-2.8.1' 
#'release-2.8.3' #'release-2.8.6' #stable)

ConfigurationOfXPath-monty.90 loads fine.

Best regards,
Henrik

Re: [Pharo-dev] Ombu losing file on folder renaming

[Damien Pollet]

The path you copied corresponds to before, or after the rename ?

On 8 September 2016 at 09:27, stepharo  wrote:

> Hi Martin
>
> I often get
>
> Information
> Ombu: Couldn't write entry, since FileDoesNotExist: File @
> /Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/
> PharoHarvestingFixes/60/current/pharo-local/ombu-sessions/
> Pharo_ajxqkxc.ombu
>
> And this happens when I save and close the image, renamed the folder and
> reopen the image.
>
> Stef
>
>
>
>


-- 
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

Re: [Pharo-dev] [Pharo-users] Small OS-... project addition

[Esteban Lorenzano]

> On 08 Sep 2016, at 15:55, Alexandre Bergel  wrote:
> 
> Pretty cool!
> Is it available from the catalog?
> 
> Alexandre
> 
> 
>> On Sep 8, 2016, at 4:06 AM, Torsten Bergmann  wrote:
>> 
>> Hi,
>> 
>> now also the OSX project in the OS series [1] has support to 
>> 
>> - directly open a terminal 
>> - directly open a file browser (Finder) on the working directory
>> 
>> right from the Pharo tools menu. See attached screenshot.
>> 
>> Depending on your platform just load
>> 
>> - OSOSX
>> - OSWindows
>> - OSLinuxUbuntu
>> - OSLinuxCentOS
>> 
>> from catalog.

^ this :)

>> 
>> Bye
>> T.
>> 
>> 
>> [1] http://smalltalkhub.com/#!/~OS
> 
> 

Re: [Pharo-dev] [Pharo-users] Small OS-... project addition

[Alexandre Bergel]

Pretty cool!
Is it available from the catalog?

Alexandre


> On Sep 8, 2016, at 4:06 AM, Torsten Bergmann  wrote:
> 
> Hi,
> 
> now also the OSX project in the OS series [1] has support to 
> 
> - directly open a terminal 
> - directly open a file browser (Finder) on the working directory
> 
> right from the Pharo tools menu. See attached screenshot.
> 
> Depending on your platform just load
> 
> - OSOSX
> - OSWindows
> - OSLinuxUbuntu
> - OSLinuxCentOS
> 
> from catalog.
> 
> Bye
> T.
> 
> 
> [1] http://smalltalkhub.com/#!/~OS

[Pharo-dev] Deactivated Locale Still Sets TimeZone

[Sean P. DeNigris]

I was surprised to find that Pharo kept setting my local offset, even though
I explicitly set it to UTC and then made sure Locale was disabled. Then I
saw:
Locale class>>#startUp: resuming
...
DateAndTime localTimeZone: self localTimeZone.
(self activated)
ifTrue: [

First it does some work, and then it checks to see whether it's activated! I
propose to move the first line into the subsequent block, or maybe better
yet - move that behavior into DateAndTime itself. Thoughts?



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Deactivated-Locale-Still-Sets-TimeZone-tp4914754.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] SystemLogger in Pharo 5

[Sean P. DeNigris]

NorbertHartl wrote
> Since 20 minutes there is :)

Ha ha, thanks!



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/SystemLogger-in-Pharo-5-tp4914695p4914752.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] SystemLogger in Pharo 5

[Norbert Hartl]

> Am 08.09.2016 um 14:24 schrieb Sean P. DeNigris :
> 
> NorbertHartl wrote
>> I started today to build my first project using Beacon instead of
>> SystemLogger
> 
> That's what I ended up doing as well and it fit my needs nicely. I just
> loaded the #development version as there is no #stable declared for Pharo
> 5.0.
> 
> 
Since 20 minutes there is :)

Remember to load ConfigurationOfBeacon and not ConfigurationOfBeaconCore. If 
you loaded the stable before please note that quite some things have changed.

Norbert

Re: [Pharo-dev] SystemLogger in Pharo 5

[Sean P. DeNigris]

NorbertHartl wrote
> I started today to build my first project using Beacon instead of
> SystemLogger

That's what I ended up doing as well and it fit my needs nicely. I just
loaded the #development version as there is no #stable declared for Pharo
5.0.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/SystemLogger-in-Pharo-5-tp4914695p4914747.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] FileDoesNotExist vs. FileDoesNotExistException

[Esteban Lorenzano]

> On 08 Sep 2016, at 09:03, Guille Polito  wrote:
> 
> I'd argue also for consistency. When some exceptions are named "Exception" 
> and others are not, my eyes hurt.

+1

> 
>  Original Message 
>> My very first thoughts are...
>> 
>> On Thu, Sep 8, 2016 at 3:35 AM, stepharo  wrote:
>>> Hi guys
>>> 
>>> in
>>> https://pharo.fogbugz.com/f/cases/19026/Merge-FileDoesNotExist-and-FileDoesNotExistException
>>> sven proposed to have
>>> 
>>> FileDoesNotExist and remove the FileDoesNotExistException
>> This seems quite reasonable.  It would be very hard to confuse the
>> semantics of FileDoesNotExist with something else.  Also this is
>> probably something end-user-devs will use more frequently in their
>> application, so less verbose is better.
>> 
>> The only thing that crosses my mind is perhaps discoverability... in
>> Spotter searching on "File" the drilling into classes and searching on
>> "Exception".Oh I just tried in Pharo 5 and it worked, there are
>> four.   The other way to handle that might be for Spotter to have a
>> "KindOf" search.
>> 
>> btw, in the Spotter preview pane when a class is selected, could the
>> class comment be displayed?
>> 
>>> Before doing it I would like to have your point of view on the names. For
>>> now I'm neutral and indeed if we apply it to exception
>>> 
>>> it seems to work for announcement. Now in Spec I was planning to put nearly
>>> systematically Presenter at the end of Presenters :).
>> Spec has more interrelated design pattern components.  Its seems there
>> has been some confusion around the nomenclature of these components.
>> So the additional hint is probably beneficial.
>> 
>> cheers -ben
>> 
> 
> 

Re: [Pharo-dev] SystemLogger in Pharo 5

[Norbert Hartl]

Yes, I use it quite a while but only with pharo4.
As we are settling the SystemLogger/Beacon case I started today to build my 
first project using Beacon instead of SystemLogger. The logger side of Beacon 
is more or less the stuff from SystemLogger integrated there. With a few more 
iterations we come up with a stable logger side and then I'd consider 
SystemLogger deprecated.

Norbert

> Am 08.09.2016 um 09:37 schrieb stepharo :
> 
> Hi Sean
> 
> It is stable since then. I do not have the time to look at it now.
> 
> I know norbert is using it in production since years.
> 
> 
> Stef
> 
> 
> Le 8/9/16 à 03:56, Sean P. DeNigris a écrit :
>> The Catalog has it tagged Pharo5.0, but there is no stable version declared
>> for > Pharo 3
>> 
>> 
>> 
>> -
>> Cheers,
>> Sean
>> --
>> View this message in context: 
>> http://forum.world.st/SystemLogger-in-Pharo-5-tp4914695.html
>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>> 
>> 
> 
> 

Re: [Pharo-dev] Small OS-... project addition

[Tudor Girba]

Nice!

Doru


> On Sep 8, 2016, at 9:06 AM, Torsten Bergmann  wrote:
> 
> Hi,
> 
> now also the OSX project in the OS series [1] has support to 
> 
> - directly open a terminal 
> - directly open a file browser (Finder) on the working directory
> 
> right from the Pharo tools menu. See attached screenshot.
> 
> Depending on your platform just load
> 
> - OSOSX
> - OSWindows
> - OSLinuxUbuntu
> - OSLinuxCentOS
> 
> from catalog.
> 
> Bye
> T.
> 
> 
> [1] http://smalltalkhub.com/#!/~OS

--
www.tudorgirba.com
www.feenk.com

"Things happen when they happen,
not when you talk about them happening."

Re: [Pharo-dev] SystemLogger in Pharo 5

[stepharo]

Hi Sean

It is stable since then. I do not have the time to look at it now.

I know norbert is using it in production since years.


Stef


Le 8/9/16 à 03:56, Sean P. DeNigris a écrit :

The Catalog has it tagged Pharo5.0, but there is no stable version declared
for > Pharo 3



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/SystemLogger-in-Pharo-5-tp4914695.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] Ombu losing file on folder renaming

[stepharo]

Hi Martin

I often get

Information
Ombu: Couldn't write entry, since FileDoesNotExist: File @ 
/Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/PharoHarvestingFixes/60/current/pharo-local/ombu-sessions/Pharo_ajxqkxc.ombu


And this happens when I save and close the image, renamed the folder and 
reopen the image.


Stef

[Pharo-dev] Small OS-... project addition

[Torsten Bergmann]

Hi,

now also the OSX project in the OS series [1] has support to 

 - directly open a terminal 
 - directly open a file browser (Finder) on the working directory

right from the Pharo tools menu. See attached screenshot.

Depending on your platform just load

 - OSOSX
 - OSWindows
 - OSLinuxUbuntu
 - OSLinuxCentOS

from catalog.

Bye
T.


[1] http://smalltalkhub.com/#!/~OS

Re: [Pharo-dev] FileDoesNotExist vs. FileDoesNotExistException

[Guille Polito]

I'd argue also for consistency. When some exceptions are named 
"Exception" and others are not, my eyes hurt.


 Original Message 

My very first thoughts are...

On Thu, Sep 8, 2016 at 3:35 AM, stepharo  wrote:

Hi guys

in
https://pharo.fogbugz.com/f/cases/19026/Merge-FileDoesNotExist-and-FileDoesNotExistException
sven proposed to have

FileDoesNotExist and remove the FileDoesNotExistException

This seems quite reasonable.  It would be very hard to confuse the
semantics of FileDoesNotExist with something else.  Also this is
probably something end-user-devs will use more frequently in their
application, so less verbose is better.

The only thing that crosses my mind is perhaps discoverability... in
Spotter searching on "File" the drilling into classes and searching on
"Exception".Oh I just tried in Pharo 5 and it worked, there are
four.   The other way to handle that might be for Spotter to have a
"KindOf" search.

btw, in the Spotter preview pane when a class is selected, could the
class comment be displayed?


Before doing it I would like to have your point of view on the names. For
now I'm neutral and indeed if we apply it to exception

it seems to work for announcement. Now in Spec I was planning to put nearly
systematically Presenter at the end of Presenters :).

Spec has more interrelated design pattern components.  Its seems there
has been some confusion around the nomenclature of these components.
So the additional hint is probably beneficial.

cheers -ben

Re: [Pharo-dev] FileDoesNotExist vs. FileDoesNotExistException

[Guille Polito]

I'd argue also for consistency. When some exceptions are named 
"Exception" and others are not, my eyes hurt.


 Original Message 

My very first thoughts are...

On Thu, Sep 8, 2016 at 3:35 AM, stepharo  wrote:

Hi guys

in
https://pharo.fogbugz.com/f/cases/19026/Merge-FileDoesNotExist-and-FileDoesNotExistException
sven proposed to have

FileDoesNotExist and remove the FileDoesNotExistException

This seems quite reasonable.  It would be very hard to confuse the
semantics of FileDoesNotExist with something else.  Also this is
probably something end-user-devs will use more frequently in their
application, so less verbose is better.

The only thing that crosses my mind is perhaps discoverability... in
Spotter searching on "File" the drilling into classes and searching on
"Exception".Oh I just tried in Pharo 5 and it worked, there are
four.   The other way to handle that might be for Spotter to have a
"KindOf" search.

btw, in the Spotter preview pane when a class is selected, could the
class comment be displayed?


Before doing it I would like to have your point of view on the names. For
now I'm neutral and indeed if we apply it to exception

it seems to work for announcement. Now in Spec I was planning to put nearly
systematically Presenter at the end of Presenters :).

Spec has more interrelated design pattern components.  Its seems there
has been some confusion around the nomenclature of these components.
So the additional hint is probably beneficial.

cheers -ben