Re: [Pharo-dev] [Pharo-users] About strange email related to smalltalkhub read-only on squeak-dev

[Richard Sargent]

Thanks, Bruce. The part about (the possibility that) squeak source is
configured to restrict distribution was the missing piece for me. I had
previously assumed (hah!) that it would be available to anyone anywhere.


On Sun, May 31, 2020, 10:39 Bruce O'Neel  wrote:

>
> Hi,
>
> So addressing only the crypto software issue and with the caveat that I am
> also not a lawyer but I have had to deal with certain aspects of this in
> the past
>
> Crypto software is one of those bizarre dual use items in terms of arms
> imports and exports.  While we as geeks just think of this is software or
> mathematics and might be confused as to why governments care, governments
> do care deeply about this.  And their way of expressing how much they care
> about this issue is by passing laws and prosecuting folks.
>
> One of the easiest ways to get in trouble is for one to make the software
> available to residents and/or citizens of certain countries as well as
> available to people on a long list kept by different governments.  We can
> have a long debate about the morality of this concept but those who make
> the laws have decided that is the law.  And often these laws are crafted
> such that the executive can change important details on short notice and
> that puts the risk of prosecution at the whims of different world leaders.
>
> The license that the software is released under is not important.
>
> What Ron is stating is that squeak source supplied some additional
> protections to prevent accidentally making the software available to folks
> who the US feels should not have access.
>
> If you have moved the software to another hosting provider without the
> permission or knowledge of the author, and therefore the owner of the
> software, you have put that person at additional risk.  In addition you and
> the hosting provider are taking on additional risk.
>
> If it was moved to GitHub I strongly recommend reviewing their policies on
> trade controls and what risks you assume.
>
> https://help.github.com/en/github/site-policy/github-and-trade-controls
>
>
> Finally I would strongly recommend talking to a competent legal advisor
> who is deeply familiar with the details of these laws.  They are complex
> and highly variable between different parts of the world.
>
> I know this seems like a lot of trouble and wasted time but you can spend
> a giant amount of time and money defending oneself from arms trafficking
> charges.
>
> cheers
>
> bruce
>
> *30 May 2020 14:43 Stéphane Ducasse  > wrote:*
>
> Hi all
>
> This is the week-end and we worked super well yesterday during the sprint.
> Lot of good enhancements - Thanks a lot to all the participants.
> I not really happy to be forced to do it on a sunny saturday but I’m doing
> it to clarify points.
>
> Esteban sent me this text that was posted on Squeak-Dev (I personally do
> not read squeak related forums because
> I have not the time and my focus is Pharo, its consortium, my team, my
> research and my family).
>
> We have to react because
> - We do not really at ***all** understand this email
> - We did not kicked anybody from our mailing-list from ages - so ron is
> lying. In the past we even had discussion with ron - so we do not
> really understand. May be we got problem to log on our mailing-lists.
> We have no idea because we are working and not looking at such things.
> - When we migrated smalltalkhub to readonly we payed attention to make
> sure that private projects stay private.
> We did not migrated smalltalkhub for fun. We MUST do it or it will be done
> by our infrastructure!
> - Now the cryptography packages are MIT and they are public anyway. So
> again we do not understand anything.
>
> We do not get why Ron contacted us because we announced the migration
> publicly way in advance and we will keep
> the Smalltalkhub frozen repo for at least next 5 years.
>
> I feel really sorry to hear such kind of email because we do not want to
> fight with anybody.
> Our goal is to make sure that people can work with Pharo and expand their
> business and knowledge.
> We are working hard to make sure that people can invent their future with
> Pharo and people that know us personally
> know that we are not lying.
>
> S
>
>
>
> Hi all,
>
> I've tried to work with the Pharo group but they keep kicking me out of
> their mailing list.  I've already mentioned this a number of times to the
> Pharo group but nobody seems to care.
>
> BOLD BOLD BOLD PLEASE TAKE THIS SERIOUSLY  BOLD BOLD BOLD
>
> I am not a lawyer but we used very good lawyers to make the squeaksource
> repository a safe place to do cryptography work.  If you are working on
> cryptography DO NOT POST your code anywhere except squeaksource.
> Especially if you are in the USA.  The ONLY repository that is approved to
> host our cryptography code in the USA and therefore not subject to criminal
> violations is squeaksource.  It is a CRIME in the USA to move code and make
> it available on the internet for everyone

Re: [Pharo-dev] [Pharo-users] [Pharo-Launcher] call for tests on Windows

[Richard Sargent]

The good news is that the same version of Pharo Launcher worked essentially
perfectly under Windows 10.

As expected, the launcher was installed in AppData\Local.
However, I continue to find an AppData\Roaming\pharo directory created when
the launcher was installed. Its contents are as I described in the issue
created for the Windows 7 installation.


Suggestion:
Some of the lists are quite long. It might be useful to be able to sort
them by e.g. name or date of last change, both ascending and descending.



On Mon, Apr 16, 2018 at 9:54 AM, Richard Sargent <
richard.sarg...@gemtalksystems.com> wrote:

> I ran the launcher against my Windows 7 office computer and have created
> an issue with my feedback.
> https://github.com/pharo-project/pharo-launcher/issues/93
>
>
>
> On Mon, Apr 16, 2018 at 7:13 AM, Christophe Demarey <
> christophe.dema...@inria.fr> wrote:
>
>> Hi,
>>
>> Regarding the various problems Pharo Launchers had on Windows, we worked
>> on a new installer based on Advanced Installer [1] to avoid UAC (User
>> Account Control) and write permissions problems. This new installer now
>> installs Pharo Launcher in the user’s local app data folder (where for
>> sure, he has write permissions). Pharo Launcher also now have its own icon
>> and use its own name instead of Pharo. Also, the uninstaller now works as
>> expected. Last but not least, the installer is now signed to avoid warning
>> of Windows Defender.
>> Thanks to Ben Coman who did the first version of the packaging using
>> Advanced Installer (was NSIS).
>> This version should also improve the launch of Pharo images on Windows.
>>
>> So, please could you install and test this new version: and report any
>> problem with it? http://files.pharo.org/pharo-launcher/win-alpha/
>> We do not have windows users around so it’s hard to know if it works
>> outside our tests boxes.
>>
>> Thanks,
>> Christophe
>>
>> [1] https://www.advancedinstaller.com/
>>
>
>

Re: [Pharo-dev] [Pharo-users] [Pharo-Launcher] call for tests on Windows

[Richard Sargent]

I ran the launcher against my Windows 7 office computer and have created an
issue with my feedback.
https://github.com/pharo-project/pharo-launcher/issues/93



On Mon, Apr 16, 2018 at 7:13 AM, Christophe Demarey <
christophe.dema...@inria.fr> wrote:

> Hi,
>
> Regarding the various problems Pharo Launchers had on Windows, we worked
> on a new installer based on Advanced Installer [1] to avoid UAC (User
> Account Control) and write permissions problems. This new installer now
> installs Pharo Launcher in the user’s local app data folder (where for
> sure, he has write permissions). Pharo Launcher also now have its own icon
> and use its own name instead of Pharo. Also, the uninstaller now works as
> expected. Last but not least, the installer is now signed to avoid warning
> of Windows Defender.
> Thanks to Ben Coman who did the first version of the packaging using
> Advanced Installer (was NSIS).
> This version should also improve the launch of Pharo images on Windows.
>
> So, please could you install and test this new version: and report any
> problem with it? http://files.pharo.org/pharo-launcher/win-alpha/
> We do not have windows users around so it’s hard to know if it works
> outside our tests boxes.
>
> Thanks,
> Christophe
>
> [1] https://www.advancedinstaller.com/
>

Re: [Pharo-dev] Ugly smell: really long symbols/selectors

[Richard Sargent]

Guillermo Polito wrote
> but wait, I've just shown that more than 2/3s of them are not test
> selectors...

Well, quit teasing us. :-) Show us the list (longest to shortest order).

I agree with you that it is a code smell and you are right to be suspicious.
I'm inclined to say that if the method name is a novella, the method is
probably doing too much or the method name is trying to explain too much
about the method's internals.



> On Wed, Aug 16, 2017 at 2:21 PM, Denis Kudriashov <

> dionisiydk@

> >
> wrote:
> 
>> Which is actually shows that tests as methods are not really good idea.
>> Tests are supposed to be documentation but with classic SUnit we have
>> only
>> two ways (classes and methods) to decompose them which is definitely not
>> enough for docs.
>> But ignore it. I am just thinking aloud :)
>>
>> 2017-08-16 13:47 GMT+02:00 Stephane Ducasse <

> stepharo.self@

> >:
>>
>>> I often use long selectors for tests :)
>>>
>>>
>>> On Wed, Aug 16, 2017 at 9:49 AM, Guillermo Polito <
>>> 

> guillermopolito@

>> wrote:
>>>
 (ByteSymbol allInstances select: [ :e | e size > 50 ]) size
 "638"
 (ByteSymbol allInstances select: [ :e | e size > 50 and: [ e
 beginsWith:
 'test' ] ]) size
 "200"

 Still 438 non test selectors. Some of them are class creation methods
 (#subclass:instanceVariables:...)

 I'm just saying this is a smell, wanted to share some of my catarsis
 :).

 Guille

 On Wed, Aug 16, 2017 at 9:35 AM, Nicolas Cellier <
 

> nicolas.cellier.aka.nice@

>> wrote:

> Hi Guile,
> have you inspect-ed the list?
> I wouldn't be surprise that these are whole sentence acting as
> specification in unit TestCase,
> like whenBrowserReceiveOpenItShouldReturnTheWindowMorph...
>
> 2017-08-16 3:51 GMT+02:00 Guillermo Polito <

> guillermopolito@

> >:
>
>> #'thisIsAVeryLongSelectorAndIfYoureHereWeHaveOnly49ImagineIH
>> aveToWriteAllThisToArriveTo87ThenThisTo100'
>>
>> (ByteSymbol allInstances select: [ :e | e size > 100 ]) size
>>   => 36
>>
>> (ByteSymbol allInstances select: [ :e | e size between: 50 and: 100
>> ])
>> size
>>   => 653
>>
>>
>> --
>>
>>
>>
>> Guille Polito
>>
>>
>> Research Engineer
>>
>> French National Center for Scientific Research - *http://www.cnrs.fr*
>> ;
>>
>>
>>
>> *Web:* *http://guillep.github.io* ;
>>
>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>>
>
>


 --



 Guille Polito


 Research Engineer

 French National Center for Scientific Research - *http://www.cnrs.fr*
 ;



 *Web:* *http://guillep.github.io* ;

 *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>

>>>
>>>
>>
> 
> 
> -- 
> 
> 
> 
> Guille Polito
> 
> 
> Research Engineer
> 
> French National Center for Scientific Research - *http://www.cnrs.fr*
> ;
> 
> 
> 
> *Web:* *http://guillep.github.io* ;
> 
> *Phone: *+33 06 52 70 66 13





--
View this message in context: 
http://forum.world.st/Ugly-smell-really-long-symbols-selectors-tp4961544p4961707.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Security in the image

[Richard Sargent]

LaeMing wrote
> 
> Stephan Eggermont wrote
>> On 12/04/17 09:34, LaeMing wrote:
>>> What sort of security implications might that have and are there any
>>> current
>>> solutions to a multi-user single-image situation?
>> 
>> Take a look at gemstone.
>> https://www.youtube.com/user/JamesGFoster/videos
>> Starting at https://www.youtube.com/watch?v=U0z5TddqyQI
>> James made a really good series of videos
>> 
>> 
>> Stephan
> Thanks, Stephan.
> Gem looks rather good, but I need an OSS licensed environment.

Can you elaborate on that? GemStone/S has a free, even for commercial use,
license. Are you planning on modifying the VM or the base product code?





--
View this message in context: 
http://forum.world.st/Security-in-the-image-tp4941857p4942128.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] Any plans for locale-specific printing and parsing of Date, Time, Number, etc.?

[Richard Sargent]

I think the title pretty well states it. I see nothing in the Pharo 5.0
download that allows locale-specific printing. Is there a well-defined API
available? Is it on the road map for a future Pharo version? (If so, for any
specific version?)


Thanks!




--
View this message in context: 
http://forum.world.st/Any-plans-for-locale-specific-printing-and-parsing-of-Date-Time-Number-etc-tp4940815.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] strange idea about slots

[Richard Sargent]

Ben Coman wrote
> I'm not sure I'm thinking straight, but I wonder...
> Can you put Slots inside an Association?
> 
> For example, could have two slots x and y,
> and then be able to do the following...
> 
> (x -> y) substitute: (1 -> 2).
> self assert: x equals: 1.
> self assert: y equals: 2.
> 
> So the association method #substitute:
> assigns into the relevant variables.
> 
> And even better if you could do...
> (x -> y) := (1 -> 2).
> and...
> { x. y ) := #(1 2).
> 
> For example, when you're hacking fast and want to return two values from a
> method without mucking around with creating an object for this, it might
> look like...
> myCalc
> ^#(1 2)
> 
> but instead of...
> result := inst myCalc.
> x := result at: 1.
> y := result at: 2.
> 
> you could do...
> { x . y } := inst myCalc.

I see this often, and even practice it sometimes. :-(

But every time I think about it, I get frustrated. We have no problem
creating instances of an existing class (Array, Association, even
Dictionary) to return multiple values from a method.

However, I always feel like doing so abdicates our responsibilities. At
least with a Dictionary, the values are properly identified rather than
stuffed into an anonymous collection or mis-represented as key and value.

Ultimately, I always conclude that this anti-pattern indicates a modelling
failure. Why not create a class which does the computation, holds the
several desired result objects, and provides the ability to answer them? 

Worst case, you have a simple computation that produces more than one result
object. In such a case, create a data transfer object (no real behaviour)
that holds the results in appropriately named instance variables.


There seems to be a fear of creating new classes. Don't let that rule your
designs.



> cheers -ben





--
View this message in context: 
http://forum.world.st/strange-idea-about-slots-tp4936623p4936691.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] The 2017 Stack Overflow Developer Survey is Now Live

[Richard Sargent]

Arden Thomas reports "Questions 39 and 47 give us an opportunity to mention
Smalltalk."

http://stackoverflow.blog/2017/01/The-2017-Stack-Overflow-Developer-Survey-is-Now-Live/



--
View this message in context: 
http://forum.world.st/The-2017-Stack-Overflow-Developer-Survey-is-Now-Live-tp4929573.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] Can anyone explain #asInteger for Strings?

[Richard Sargent]

I've come across an implementation of #asInteger and #asSignedInteger in
Pharo 3.0 that leaves me scratching my head.

Can anyone explain why it was defined to answer what it does for strings
that one would really not expect to parse as a number.

'abc-123-xyz-897' asSignedInteger
===>  -123 

To my mind, the method that does this for the example string should have an
intention revealing name like #spelunkIntegerFromString or some such.


Thanks,
Richard



--
View this message in context: 
http://forum.world.st/Can-anyone-explain-asInteger-for-Strings-tp4929502.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] GitHub code analytics tools

[Richard Sargent]

Dale Henrichs-3 wrote
> Guillermo,
> 
> Apparently you don't like the github browser-based code review tool?
> 
> What are your objections?
> 
> Do you know of a better tool that is out in the wild or do you just have 
> visions that code review could be better?

Let me add some thoughts on review tools, not as an argument against
anything in this thread, but more like nostalgia for what I have used in the
past and would like to see again. What I describe was specifically oriented
toward 1:1 peer reviews and self reviews.

VA Smalltalk has a difference browser which has the usual browser top panes
(in the case of VA, showing Application, Class, and Method lists) and
side-by-side bottom panes showing the two versions of the code for the
selection in the top panes. It also has a button that allows you to step
through the changes, highlighting each successive difference. (It also has
substantial room for improvements!)

The things I like about it are:
- it's live in my image, so all the usual things one can do with Smalltalk
are possible
- I can easily review other versions of the artefacts
- I can jump around to follow related artefacts (e.g., look at a changed
method called from the current one or vice versa)
- I can *remove artefacts from the lists* as I finish with them so that my
browser works as a structured check list and as I eliminate things I can can
see what remains and eventually empty the lists, signifying completion
- I can modify the changes to correct problems with them and then publish an
updated change (or in Git terms a new commit)


So, these are some of the characteristics I would like to find in a review
tool.



> Better tools are always possible, but it is sometimes nice to use a tool 
> that you didn't have to build from scratch while creating the better
> tool:)
> 
> Dale
> 
> On 10/27/2016 05:06 AM, Guillermo Polito wrote:
>> I would like to have a good code review tool, before having to do one 
>> ad-hoc...
>>
>> On Thu, Oct 27, 2016 at 1:50 PM, Denis Kudriashov 
>> <

> dionisiydk@

>   dionisiydk@

> >> wrote:
>>
>> Hi.
>>
>> With future transition to github I ask myself what tools we will
>> have out of the box.
>> I google a bit and found these nice service http://ghv.artzub.com.
>> Try to search guillep and then pharo-core. It looks really nice.
>>
>> What other online services you know to analyse github projects?
>>
>>





--
View this message in context: 
http://forum.world.st/GitHub-code-analytics-tools-tp4920385p4920581.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] New to Pharo; a bunch of questions.

[Richard Sargent]

CodeDmitry wrote
> Ok I got the proof of concept down, but I can't get it all to run at once
> since Pharo realizes that the class does not exist(at the time of
> running), even though it will exist by the time it gets to that line.
> 
> Is there a way to modify the following Transcript code make the following
> code run "one block at a time". Ignoring the fact that classes are not
> created at time of writing?
> 
> I think I need some way to "reflectively find a class by class name at
> runtime".

> steps.st

> ([
> SimpleSwitchMorph subclass: #LOCell
> instanceVariableNames: 'mouseAction'
> classVariableNames: ''
> package: 'PBE-LightsOut'
> ] value).
> 
>  
/
> 
/
Well, that was an excruciating read. Did you find it easy to read? I'll bet
you also found it hard to write.

If you look at the file-out format (also called chunk format), you can just
simply write the code you want as a result and it would be infinitely more
comprehensible to you and to those you would share it with.

There are times when writing things along the lines that you have are
essential. For example, if you are writing a code generator you would want
to generate source strings and compile them.



--
View this message in context: 
http://forum.world.st/New-to-Pharo-a-bunch-of-questions-tp4917701p4917927.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] New to Pharo; a bunch of questions.

[Richard Sargent]

CodeDmitry wrote
> It's just nice to have a standalone code that I can give to my friends
> that they can read and run to create the structure without having to setup
> everything themselves, but at the same time not needing to use a package. 
> 
> A standalone script is quite elegant for situations like that, since it
> well encapsulates the automation without forcing people to understand
> packaging.
> 
> I don't mind shooting myself in the foot, I want to understand how Pharo
> runtime works, it has this strange circularity to it that I can't quite
> wrap my mind around.
> 
> I just like doing everything in Code if possible. I see no reason to use
> the browser other to inspect system state at the moment.

Bear in mind, the browsers were created by the original authors to
facilitate repetitive actions. They are tools for interacting with the
objects in the system, just as are the debugger and inspector.


That being said, I do agree i is important to understand how the tools do
what they do. You should definitely browse the Behavior hierarchy. It
contains all the code for creating classes, compiling (and installing!)
methods, removing methods, and so on.


Also, I noticed in your examples that you like to write ([ ... ] value).
Why? Why not just write the actual code (shown as ... in my example)?



> Personally I've never had more fun with Smalltalk as I did writing this
> proof of concept.





--
View this message in context: 
http://forum.world.st/New-to-Pharo-a-bunch-of-questions-tp4917701p4917926.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] New to Pharo; a bunch of questions.

[Richard Sargent]

CodeDmitry wrote
> @askoh
> 
> Ryerson University, Pragmatic Programming Languages teaches Smalltalk, and
> Introduction to Object Oriented Programming does too.

Well, be sure to check out the Toronto Smalltalk User Group!
http://www.smalltalk.ca/ says they meet at Ryerson. I'm not sure that's
always / still true. But you will be welcomed.


> There was also a club I think where people did Smalltalk coding, but I
> never really visited it so I may have been lied to.
> 
> @stepharo 
> 
> heh you're right! I haven't noticed that feature, it's handy. 
> 
> Umm I created a category Dummy, with class Dumbo, with method meep that
> does trivial text printing, and file-out'd it, but I don't know how to put
> it back in, it's not a valid Playground-script.
> 
> Object subclass: #Dumbo
>   instanceVariableNames: ''
>   classVariableNames: ''
>   poolDictionaries: ''
>   category: 'Dummy'!
> 
> !Dumbo methodsFor: 'as yet unclassified' stamp: 'Anonymous 10/2/2016
> 21:19'!
> meep
> Transcript show: 'Hello, World!!'.! !





--
View this message in context: 
http://forum.world.st/New-to-Pharo-a-bunch-of-questions-tp4917701p4917925.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Getting Pharo to Mars?

[Richard Sargent]

Clément Bera-4 wrote
> The first thing is to get naturalised as a US citizen.

I think you would be much further ahead to find someone who works for the
ESA. 
(Or maybe approach the ESA itself directly!)



> It seems that the space market has been opened to private companies in the
> US, but they're still quite skeptical about sharing knowledge with non
> american citizens. If you want to work with Space X, you have either to be
> an american citizen or have something they really really really want to
> convince them to work with you (and even so, it's likely your native
> country matters).
> 
> Quoting their website:
> 
> *To conform to U.S. Government space technology export regulations,
> applicant must be a U.S. citizen, lawful permanent resident of the U.S.,
> protected individual as defined by 8 U.S.C. 1324b(a)(3), or eligible to
> obtain the required authorizations from the U.S. Department of State.
> Learn
> more about ITAR here.*
> 
> 
> 
> On Thu, Sep 29, 2016 at 6:27 AM, 

> phil@

>  <

> phil@

> >
> wrote:
> 
>> Given
>>
>> http://waitbutwhy.com/2016/09/spacexs-big-fking-rocket-the-full-story.html
>>
>> we should find some way to get Pharo into it somehow.
>>
>> Anyone having ideas on how to do that?
>>
>> Phil
>>





--
View this message in context: 
http://forum.world.st/Getting-Pharo-to-Mars-tp4917390p4917478.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Binary selector and special characters

[Richard Sargent]

Nicolai Hess-3-2 wrote
> 2016-08-31 17:31 GMT+02:00 John Brant <

> brant@

> >:
> 
>> On 08/31/2016 08:46 AM, Nicolai Hess wrote:
>>
>> Anyone knows why RefactoringBrowsers smalltalk scanner (RBScanner)
>>> explicit allowes
>>>   "#($± $· $× $÷)" to be binary selector characters ?
>>>
>>
>> I do -- I added them about 20 years ago :)...
>>
>> Is there any smalltalk dialect that uses these characters ?
>>>
>>
>> VW allows them. When possible, we made the scanner/parser be a superset
>> of
>> the VW & VA syntax.
>>
>>
>> John Brant
>>
>>
> Thank you John, for the info.
> Hm, now, what to do, fix our (pharo) parser to allowe these characters as
> binary selectors or change the scanner to not
> generate binary selector tokens for them...

I would argue that when Zerox PARC created Smalltalk ASCII was all they had
to choose from. 40 years later, we have Unicode and we have people from
around the world using Smalltalk. Most of them are not native English
speakers.

Having a Smalltalk implementation that supports Unicode selectors, unary,
binary, or keyword, would be a good and welcome things.




--
View this message in context: 
http://forum.world.st/Binary-selector-and-special-characters-tp4912981p4913685.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Abotu FileReference objects as autoevaluating ones

[Richard Sargent]

stepharo wrote
> about 
> https://pharo.fogbugz.com/f/cases/18956/FileReference-printString-should-be-auto-evaluable
> 
> 
> 'tmp/foo.txt' asFileReference
>  >
> File @ tmp/foo.txt
> 
> and it would be much much better to get back
> 'tmp/foo.txt' asFileReference
> 
> So that we can get
> { 'tmp/foo.txt' asFileReference }
>  > { 'tmp/foo.txt' asFileReference }
> 
> and not
>   "an Array(File @ tmp/foo.txt)"
> 
> 
> In addition we should turn the current printOn: method into a 
> displayString method so that
> a list of fileReference can be well display with File @ tmp/foo.txt for 
> example

In many Smalltalk implementations, there are (at least) three behaviours for
this kind of thing: #storeString, #printString, and #displayString. I would
argue against conflating them.


Examples:
(I am not saying this is how each should work, just providing examples of
how each /might/ differ to suit the different constituencies for each one's
use case.)

1) #displayString
'/directory/file' asFileReference displayString ==> '/directory/file'
'/directory' asFileReference displayString ==> '/directory/'

2) #storeString
'/directory/file' asFileReference storeString==> '/directory/file'
asFileReference
'/directory' asFileReference storeString==> '/directory/' asFileReference

3) #printString
'/directory/file' asFileReference printString ==>
FileReference(/directory/file)
'/directory' asFileReference printString ==> FileReference(/directory/)





--
View this message in context: 
http://forum.world.st/Abotu-FileReference-objects-as-autoevaluating-ones-tp4911694p4911974.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Having comments for pragma?

[Richard Sargent]

Tudor Girba-2 wrote
> Hi,
> 
>> On Jun 27, 2016, at 7:55 PM, Eliot Miranda <

> eliot.miranda@

> > wrote:
>> 
>> Hi Doru,
>> 
>> On Mon, Jun 27, 2016 at 6:36 AM, Tudor Girba <

> tudor@

> > wrote:
>> Hi Eliot,
>> 
>> I agree with most things you say (except the conclusion :)), and I think
>> that we are talking about complementary issues.
>> 
>> As I mentioned before, there already is a need to distinguish between a
>> plain selector and one that is associated with pragmas. This is what you
>> find in PragmaType in Spotter and Inspector. This is a kind of
>> meta-object and having it adds value. I can search for pragmas “type” (we
>> can also call it a PragmaSelector), and I can distinguish between all
>> occurrences of a pragma “type” and its utilization in computation. But,
>> the current implementation of PragmaType is a mere pseudo-meta-object,
>> given that it has no casual connection to the runtime.
>> 
>> What we know from Smalltalk is that the analysis model does not have to
>> differ from the runtime one. The consequence is that every time we do see
>> a difference, we should investigate because we might uncover a hidden
>> need opportunity.
>> 
>> I know the VW model, and indeed, we could have something like:
>> 
>> MyConcept class>>myPragmaDefinition
>> “a comment about the pragma"
>> 
> 
>> 
>> However, this only deals with the definition of the pragma type not with
>> the internal representation. There could still well be an object that
>> encapsulates both the selector and the comment. And that object would
>> also allow us to build tools around it. We could call it a PragmaType,
>> PragmaDefinition, or even PragmaSelector. And we could get the Pragma to
>> point to this type either through an inst var or through a query (I would
>> probably prefer an instvar).
>> 
>> Well, there already /is/ a meta-object called Pragma, and it gets
>> instantiated when one accesses the compiled method via pragmas:
>> 
>> (CompiledMethod allInstances detect: [:m| m pragmas size > 1]) pragmas
>> collect: [:ea| {ea. ea class}] {{
> 
>  . Pragma} . {
> 
>  . Pragma}}
> 
> Yes I know :). An instance of Pragma denotes an concrete annotation of a
> method. I now would like a meta-object that describes all Pragma instances
> having the same selector. For example, the protocol on the class side of
> the Pragma class is actually a query protocol that is better suited for
> the instance side of a PragmaDescription meta-object. For example:
> 
>   Pragma class>>allNamed: aSymbol in: aClass
> 
> would become
> 
>   PragmaDescription>>pragmasIn: aClass
> 
> and you would use it like:
> 
>   (PragmaDescription named: aSymbol) pragmasIn: aClass

I am concerned with this proposal. Effectively, it says only one
person/package can ever define a pragma selector. It would interfere with
two completely independent developers from using  for their
own work.

I think it would be better to expand on  to be able to declare
the symbol, the Pragma class, the comment, etc. which would create the meta
instance you desire, but without closing off independent work.

The the expression /PragmaDescription for: #foo/ would answer a collection
of PragmaDescriptions (0 or more). Other methods in the API could be used to
answer the one and only or throw an error if not exactly one, and so on.

[I know of no way that the individual description could find /just/ its
corresponding  uses. Conversely, I know of no way that the compiler
could reliably determine that a method with  was referring to the
pragma from one declaration versus another. But, I think that is less a
problem than forcing a "Highlander" implementation.]

> Creating an instance of PragmaDescription would imply searching the image
> for the 
> 
>  definition. I would also like to have a Flyweight pool per environment
> such that we always get only one instance of a PragmaDefinition per
> selector (like it happens with Symbols).
> 
> 
>> So we could add the information you want to Pragma, and have it be lazy.
> 
> It does not quite belong to the Pragma. A comment is common to all Pragma
> instances, and having it duplicated at the instance level is less elegant.
> 
> But, looking for the users (all senders of the pragma selector - the
> methods that use the annotation) of a Pragma would be even less
> inconvenient to have on the instance side of Pragma.
> 
> 
>> The Pragma could go search for the defining class-side pragma methods and
>> use the parser to extract the comment(s) when asked.  Hence simple access
>> to pragmas, interested only in the selectors for applying, wouldn't have
>> their performance be impacted.
> 
> The design sketched above would require no runtime penalty for a Pragma
> instance. All code that works now would work identically afterwards. We
> would only have one selector in Pragma to get the corresponding
> description:
> 
> Pragma>>description
>   ^ PragmaDescription named: self selector
> 
> Alternatively, we could modify 

Re: [Pharo-dev] Having comments for pragma?

[Richard Sargent]

Ben Coman wrote
> On Fri, Jun 24, 2016 at 10:55 PM, Clément Bera <

> bera.clement@

> >
> wrote:
> 
>> Hi.
>>
>> Pragmas are selectors hence they're browsable. You can implement a method
>> somewhere with the pragma selector name that includes the documentation.
>> In
>> VW they were careful about that and most, if not all, of their pragmas
>> are
>> carefully commented this way.
>>
>>
> Should this be concentrated in a class like PragmaDocumentation, or spread
> out (I don't know how).

Since pragmas are an open set and can be added by any package, concentrating
them in one place doesn't sound like a good idea. The best place to have the
comments is with the code. If the pragmas name real selectors, comment the
implementation. If the pragmas are merely tags, comment the method that
declares them as pragmas (e.g. VisualWorks requires you to declare the
symbols as pragmas before using them).

Examples:
SUnit.TestCase class>>#testMethodTags declares a couple of pragma selectors
for instance methods.
testMethodTags
"Any method tagged with a  pragma is considered a test selector
candidate"
" tags are used to compute instance specific resources for the
tagged test. The argument is a symbol for the class name, or a binding
reference to the same."


^#(#test #uses:)

SUnit.TestCase class>>#testResourceTags declares a class method pragma for
resources.
testResourceTags
" tags are used to compute instance specific resources for 
the
tagged test. The argument is a symbol for the class name, or a binding
reference to the same."


^#(#resource)

ApplicationModel class>>menuMethodPragmas declares a whole slew of selectors
for menus. But it neglects to provide comments in it or in the list of
selectors in the Menu class.
menuMethodPragmas



^Menu pragmas

However, VW does comment the actual methods:
computedSubmenu: label nameKey: key menu: menuIDs position: position
"This pragma expects the body of the method marked with it
to answer a Menu that will be used as a submenu with the
label and position specified by the pragma."




> cheers -ben
> 
> 
>> For example, if you have the pragma 
> 
>  and you implement the method
>> MyClass class >> #foo with some comments in it and you can double click
>> on
>> the pragma 
> 
>  to select its content (foo) and press Cmd+M (or right
>> click implementors) to get to the method having the documentation.
>>
> 
> 
> 
>>
>> On Fri, Jun 24, 2016 at 3:54 PM, Alexandre Bergel <

> alexandre.bergel@

> > > wrote:
>>
>>> Hi!
>>>
>>> A pragma may be very obscure. For example, I do:
>>> Pragma allInstances anyOne
>>> => 
> 
>>>
>>> If I want to know more about this 
> 
>  is actually
>>> quite challenging.
>>> I see many methods having that pragma, but not idea what it is for.
>>> I see that Halt>>signalerContext and Process>>complete: that use that
>>> pragma somehow. But still, I have no idea when I should use that pragma
>>> in
>>> my method.
>>>
>>> What about having a way to comment pragma? Maybe something like
>>> -=-=-=-=-=-=
>>> Object subclass: #Pragma
>>> instanceVariableNames: 'method keyword arguments *comment*'
>>> -=-=-=-=-=-=
>>>
>>> And a simple way to annotate pragmas?
>>> Just an idea.
>>>
>>> Cheers,
>>> Alexandre
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>
>>





--
View this message in context: 
http://forum.world.st/Having-comments-for-pragma-tp4902987p4903138.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] GemStone/S 3.3.1 released

[Richard Sargent]

Dear GemTalk Customers,

We are pleased to announce the release of GemStone/S 64 Bit 3.3.1, a
maintenance release providing a number of important features and bug fixes,
including support for handling ICU library version changes over upgrade. We
encourage all GemStone/S customers to upgrade to this release.

Downloads and documentation for this release can be found at the following
URL:
http://gemtalksystems.com/products/gs64/

This server release includes the latest Visual Statistics Display (VSD)
release, version 5.2, with new features and fixes in particular for working
with multiple files. Documentation and VSD-only downloads, e.g. for
platforms other than your server, can be found at the following URL:
http://gemtalksystems.com/products/vsd/

Please contact GemTalk technical support if you have any trouble downloading
or upgrading.

Thank you!


Note that GemStone/S ships with a free-even-for-commercial-use license.



--
View this message in context: 
http://forum.world.st/GemStone-S-3-3-1-released-tp4902747.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Philosophy here

[Richard Sargent]

Igor Stasenko wrote
> (This philosophical post provoked by discussion in another thread where we
> talking about cases of implementing wrappers and layers of composition.)
> 
> To achieve more you shall do more.
> Usual truth thing in daily life.
> Not so true for programming.
> It actually
> 'do less to achieve more'.
> Because it's non-linear in programming. Because each line of code you add
> to the system is increasing it complexity accordingly. And that means more
> effort for future maintenance for you, or for some other unsuspecting
> victim.
> So, that's why i always look how to do less, reduce the amount of code, to
> achieve something. But not just plainly implement yet another feature, so
> its done.

Nice!

I'll add one, inspired by orbital mechanics and unlocking car doors in the
rain.

To go faster, slow down.
A slightly slower, more deliberate pace will yield greater results than
rushing headlong into something.



> 
> -- 
> Best regards,
> Igor Stasenko.





--
View this message in context: 
http://forum.world.st/Philosophy-here-tp4888073p4888456.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Catching Exceptions without any notice

[Richard Sargent]

Nicolas Cellier wrote
> Isn't catching too wide an anti-pattern?

Yes!
Just think of all the Exception subclasses which are *not* errors. This kind
of thing effectively disables them.



> 2016-03-30 13:33 GMT+02:00 Nicolai Hess <

> nicolaihess@

> >:
> 
>> Please don't do this:
>>
>> updateHeight
>> "no need to care about height, when it's logic is not customized"
>> self layout isHeightCustom ifFalse: [ ^ self ].
>> [ self bounds: (self brickBounds withHeight: self customHeight) ]
>> on: Exception
>> do: [ "just skip and do nothing" ]
>>
>> This makes debugging GLM/Brick ui/layout code with "self haltOnce"
>> impossible.
>> see
>> GLMBrickGeometryTrait>>#updateHeight
>> GLMBrickGeometryTrait>>#updateWidth
>>
>> And if you log out the raised exception, you see some calls to
>> not initialized fonts and a ZeroDevide and some more errors.
>> The above catch, catches and hides wrong / to late initialized objects.
>>





--
View this message in context: 
http://forum.world.st/Catching-Exceptions-without-any-notice-tp4887402p4887460.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Git written entirely in Smalltalk?

[Richard Sargent]

Ben Coman wrote
> Max,
> 
> The other say I was contemplating having a git implementation written
> entirely in Pharo, and today I bumped into something from your history
> (~2011?) [1]  indicating this might have been attempted.   I'm curious
> why this was abandoned in favour of libgit bindings.

I have seen a lot of "not invented here" work in the Smalltalk world over
the last 25 years. That in itself is enough reason to not reimplement
everything in native Smalltalk.

There are whole communities out there who specialize in one esoteric piece
of technology. You can stand on their shoulders or you can copy their work.
One of those appeals a lot more to me than the other.

When we bind to someone else's work, their updates are almost free to us.
Otherwise, we tie up a lot of our own resources replicating their work and
not advancing our own.


> [1] http://scg.unibe.ch/wiki/students/maxleske
> 
> cheers -ben





--
View this message in context: 
http://forum.world.st/Git-written-entirely-in-Smalltalk-tp4880274p4880430.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] GemStone/S 64 Bit 3.3, VSD 5.1.1, GBS 8.1 and 5.4.3, and GBJ 3.1.2 Releases

[Richard Sargent]

Dear GemTalk customers,

We are pleased to announce several important releases on our GemStone/S
64 Bit, GemBuilder for Smalltalk, and GemBuilder for Java product lines.

GemStone/S 64 Bit 3.3 is a major release, including many new features,
improvements, and bug fixes.
https://gemtalksystems.com/products/gs64/

This server release includes the latest Visual Statistics Display (VSD)
release, version 5.1.1.
https://gemtalksystems.com/products/vsd/

GemBuilder for Smalltalk 8.1 for VisualWorks adds support for GemStone/S
64 Bit 3.3 and includes new features and bug fixes.
https://gemtalksystems.com/products/gbs-vw/

GemBuilder for Smalltalk 5.4.3 for VA Smalltalk adds support for
GemStone/S 64 Bit 3.3 and VA Smalltalk 8.6.2, and includes bug fixes.
https://gemtalksystems.com/products/gbs-va/

GemBuilder for Java 3.1.2 adds support for GemStone/S 64 Bit 3.3,
updates the supported JDK version, and includes new features and bug fixes.
https://gemtalksystems.com/products/gbj/

As always, we encourage you to read the Release Notes and Install Guides
prior to upgrading to these latest product releases.
Please contact GemTalk Technical Support if you have any trouble
downloading or upgrading to this release.

Thank you,
The GemStone/S team 



--
View this message in context: 
http://forum.world.st/GemStone-S-64-Bit-3-3-VSD-5-1-1-GBS-8-1-and-5-4-3-and-GBJ-3-1-2-Releases-tp4876931.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] newFrom: vs. withAll:

[Richard Sargent]

stepharo wrote
> Hi guys
> 
> I was looking at the Collection chapter and I stumbled upon newFrom: and 
> I wonder what is the real
> difference between newFrom: and withAll:.
> I have the impression that there is not much difference. There are only 
> 47 senders of newFrom: in the default Pharo image.
> 
> Dictionary class>>withAll: interprets its argument as a collection of 
> values,
> whereas Dictionary class>>newFrom: expects a collection of associations.
> 
> I would really deprecate newFrom: in the future.
> 
> Stef

Absent a compelling argument for deviating from the ANSI standard, it would
be best to adhere to the standard.

#withAll: doesn't make sense to treat the argument as supplying the values,
as there is nothing to define the keys.  suggests the
only protocol needed for the argument would be #keysAndValuesDo: (but it
/isn't/ specified as such). 

ANSI specifies #withAll: as having an effect "the same as evaluating
Dictionary new addAll: newElements; yourself." #addAll: is shown with
"dictionary" for the argument name and typed as .





--
View this message in context: 
http://forum.world.st/newFrom-vs-withAll-tp4876589p4876674.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Disable assertions (design by contract)

[Richard Sargent]

Eliot Miranda-2 wrote
> Hi Richard,
> 
>> On Jan 28, 2016, at 2:15 PM, Richard Sargent <

> richard.sargent@

> > wrote:
>> 
>> Aliaksei Syrel wrote
>>> Hi
>>> 
>>> Assertions play an important role in design by contract. It is great to
>>> have assertions in Pharo out of box (Object>>#assert:). However in
>>> projects
>>> with many post- and precondition as also class invariants heavy usage of
>>> assertions decreases performance...
>>> 
>>> Would it be possible to have a compiler setting (in setting browser) to
>>> enable/disable assertions and not compile them to bytecode? Compiler
>>> should
>>> ignore the whole assertion statement with removed condition. For
>>> example:
>>> 
>>>> self assert: self hugeInvariant.
>>> 
>>> with disabled assertion hugeInvariant must not be sent.
>>> 
>>> Thanks,
>>> Alex
>> 
>> My concern with this is that this proposal requires certain selectors to
>> become /reserved/. Most SUnit variations that I have seen entail several
>> dozen methods for asserting and denying behaviours, block evaluation
>> versus
>> inline expressions, descriptive explanations, and so on. 
>> 
>> It seems to me that you would be better off sending messages to a global.
>> Instead of:
>>> self assert: self hugeInvariant.
>> have something like:
>>> Assert that: self hugeInvariant.
>> 
>> If the global Assert is bound to a stub the message is sent and ignored.
>> If
>> bound to a real assertion mechanism, it gets evaluated. Use blocks when
>> the
>> argument evaluation is expensive or expensive enough.
>>> Assert evaluationOf: [self hugeInvariant].
>> 
>> None of the names should be taken as suggestions. Just the concept.
> 
> It's a good concept, and is the object-oriented approach.  It's just that
> in practice the costs of creating blocks as assert: arguments, while
> typically much cheaper than evaluating the assert and discarding its
> result, are still significant
> 
> Hence I'm open to a compiler hack that elides the assert: or deny: and
> it's send altogether from the code.  Open but not happy; it's something I
> hold my nose to do.  But this is a style I've been using for twenty odd
> years and it is really nice to be able to write assert-laden code but not
> have to pay in production.

Thanks for the feedback, Eliot. It's appreciated.

If we have to hack, I would rather see the hack done differently. One of my
goals would be the ability to restore a production database into a test
environment without having to recompile all the methods. (Some of our
customers have systems with 30-40,000 classes!)

To that end, I was wondering about hacking the compiler to test the
association with the reference I've named Assert (but probably in a general
approach for any name). The code generator would send a specific message to
the currently bound value (one would require it to be implemented by all
objects bound to the name, just for honesty and clarity), to ask whether the
code generator should emit code to test the named receiver and skip the
whole statement if it answers true. The code would be generated in all
cases, but it would not be evaluated when the stub mechanism is associated
with Assert, since it would answer true to the skip question. Likewise, the
real assertion mechanism would answer false and the whole statement would be
evaluated.

That preceding paragraph glosses over a lot, but I hope the gist is
sufficiently clear.



> There is a ray of hope.  The Sista adaptive optimiser /will/ be able to
> elide all the cost of the block form:
> 
> ...
> self assert: [self expr].
> ...
> 
> Foo methods for assertions
> assert: aBlockOrBoolean
>^self
> 
> because there are obviously no side effects.  Whereas it will only be able
> to elide the entire thing depending on expr in the non-block form:
> 
> ...
> self assert: self expr.
> ...
> 
> But I wonder how any people would have the discipline or insight to use
> the block form.  It looks unnecessarily verbose yes?
> 
>> This also offers the benefit that assertions are practical everywhere,
>> not
>> just under a TestCase hierarchy.
> 
> Whether asserts are practicable everywhere IME depend on how useful they
> are in ongoing development.  The fact that they cost a /lot/ and slow down
> the VM simulator for Cog doesn't change the fact that it would be much
> much slower to modify the code base.
> 
> In another thread I was proposing to Gulle to use the VM simulator instead
> 

Re: [Pharo-dev] Disable assertions (design by contract)

[Richard Sargent]

Aliaksei Syrel wrote
> Hi
> 
> Assertions play an important role in design by contract. It is great to
> have assertions in Pharo out of box (Object>>#assert:). However in
> projects
> with many post- and precondition as also class invariants heavy usage of
> assertions decreases performance...
> 
> Would it be possible to have a compiler setting (in setting browser) to
> enable/disable assertions and not compile them to bytecode? Compiler
> should
> ignore the whole assertion statement with removed condition. For example:
> 
>> self assert: self hugeInvariant.
> 
> with disabled assertion hugeInvariant must not be sent.
> 
> Thanks,
> Alex

My concern with this is that this proposal requires certain selectors to
become /reserved/. Most SUnit variations that I have seen entail several
dozen methods for asserting and denying behaviours, block evaluation versus
inline expressions, descriptive explanations, and so on. 

It seems to me that you would be better off sending messages to a global.
Instead of:
> self assert: self hugeInvariant.
have something like:
> Assert that: self hugeInvariant.

If the global Assert is bound to a stub the message is sent and ignored. If
bound to a real assertion mechanism, it gets evaluated. Use blocks when the
argument evaluation is expensive or expensive enough.
> Assert evaluationOf: [self hugeInvariant].

None of the names should be taken as suggestions. Just the concept.

This also offers the benefit that assertions are practical everywhere, not
just under a TestCase hierarchy.

A second order effect is you aren't playing with the compiler to turn it on
and off, nor to extend the controlled API.





--
View this message in context: 
http://forum.world.st/Disable-assertions-design-by-contract-tp4874499p4874621.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] happy lessons from recent talks

[Richard Sargent]

Tudor Girba-2 wrote
> Hi,
> 
> I just wanted to share with you a bit of a different perspective on what
> we do around here.
> 
> Over the past half a year I gave several talks to some 1k technical people
> at industrial events like ArchConf, NDC Oslo and several others. The tour
> will continue this year at OOP, ArchConf and a couple of other places.
> These are places where people talk about mainstream techniques &
> technologies (like Java, JS, C#). For example, ArchConf is a premier
> software architecture conference in the US.
> 
> During these sessions, people get to experience Moose and Pharo through
> live demos. I use these demos as examples of how humane assessment
> (building your own analysis tools) can boost engineering decisions making
> in practice.
> 
> I consistently receive the feedback that the live programming
> possibilities from Pharo/Moose are impressive. But, more recently, there
> is something else worthy of being noted. If in previous years, nobody
> heard about what we do, this year I started to get consistently a couple
> of persons in the room that have heard something about Pharo/Moose before
> the presentation.

Excellent!


> This is huge. While a couple might not sound like much, you should
> remember that information (especially in this technical space) has the
> capability of spreading exponentially. What we have done over the past
> years starts to show results. We have to keep it up.
> 
> Happy New Year!
> 
> Cheers,
> Doru
> 
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Problem solving should be focused on describing
> the problem in a way that makes the solution obvious."





--
View this message in context: 
http://forum.world.st/happy-lessons-from-recent-talks-tp4870566p4870941.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] doing stupid things (image will become unusable)

[Richard Sargent]

Nicolai Hess-3 wrote
> Object := nil
> 
> you can evaluate that piece of code, but afterwards 
> 
> Opal checks for assignments to read only variables (method arguments for
> example)
> and signals an error if you try to modify those vars.
> But it does not check globals.
> 
> Should all Globals (OCLiteralVariable with isGlobalVar == true) be read
> only ?
> or can we distinguish global vars and class bindings?

I hope you will distinguish between class bindings and variable bindings (to
classes).

e.g. *StringClass :=String.* and *StringClass := Unicode.* should continue
to be usable.
(Assuming that classes named #String and #Unicode do exist, of course.)





--
View this message in context: 
http://forum.world.st/doing-stupid-things-image-will-become-unusable-tp4866090p4866994.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] [Cuis] Sorting Unicode strings (Re: [Unicode] collation sequences (Re: [squeak-dev] Unicode Support))

[Richard Sargent]

EuanM wrote
> Hi Todd, it's taken me til now to put my thoughts into words on this
> issue.
> 
> I think we should make it work first.  This will allow us to gain more
> insight into the issues, and create documentation about the process
> that we, as a community, understand.
> 
> If ICU is the right way to go, we can *then* "make it right".

One way to cross the Grand Canyon is to climb down the wall, assemble the
materials to build a bridge, build the bridge, cross it, then clamber up the
wall. One would learn a lot about climbing and bridge building, worthwhile
if the goal is to learn about those subjects.

Alternatively, you could use the highway bridge that was built long ago and
just cross to the other side. This is definitely my inclination.



> On 8 December 2015 at 22:36, Todd Blanchard <

> tblanchard@

> > wrote:
>> I just want to second Dale's endorsement of the ICU library.  It has been
>> around a long time (originally developed by Taligent) and it provides the
>> base unicode capabilities for an awful lot of software.
>>
>> I think it would make more sense to bring icu into Smalltalk as a
>> NativeBoost library than to spend resources reimplementing and
>> maintaining
>> it.
>>
>> -Todd Blanchard
>>
>> On Dec 8, 2015, at 11:20, Dale Henrichs <

> dale.henrichs@

> >
>> wrote:
>>
>> On 12/07/2015 11:31 PM, H. Hirzel wrote:
>>
>> Dale
>>
>> Thank you for your answer with links to the ICU library and the notes
>> about classes in Gemstone. Noteworthy that you have a class Utf8 as a
>> subclass of ByteArray.
>>
>> I understand that Gemstone uses the ICU library and thus does not
>> implement the algorithms in Smalltalk.
>>
>> I am currently looking into what the  ICU  library provides.
>>
>>





--
View this message in context: 
http://forum.world.st/Sorting-Unicode-strings-Re-Unicode-collation-sequences-Re-squeak-dev-Unicode-Support-tp4865876p4866992.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Unicode Support

[Richard Sargent]

EuanM wrote
> ...
> all ISO-8859-1 maps 1:1 to Unicode UTF-8
> ...

I am late coming in to this conversation. If it hasn't already been said,
please do not conflate Unicode and UTF-8. I think that would be a recipe for
a high P.I.T.A. factor.

Unicode defines the meaning of the code points.
UTF-8 (and -16) define an interchange mechanism.

In other words, when you write the code points to an external medium
(socket, file, whatever), encode them via UTF-whatever. Read UTF-whatever
from an external medium and re-instantiate the code points.
(Personally, I see no use for UTF-16 as an interchange mechanism. Others may
have justification for it. I don't.)

Having characters be a consistent size in their object representation makes
everything easier. #at:, #indexOf:, #includes: ... no one wants to be
scanning through bytes representing variable sized characters.

Model Unicode strings using classes such as e.g. Unicode7, Unicode16, and
Unicode32, with automatic coercion to the larger character width.




--
View this message in context: 
http://forum.world.st/Unicode-Support-tp4865139p4866610.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] Does anyone remember details of a "pro-Smalltalk" merger circa 2013?

[Richard Sargent]

I heard an anecdote of a recent merger between two companies in which one had
over 200 people supporting a Java application and the other had ~25 people
supporting a Smalltalk application. The surprising result was that the
Smalltalk application was selected for the merged company rather than the
Java one.

I would like to know which companies were involved, when this occurred, and
what the precise details were.


Thank you!



--
View this message in context: 
http://forum.world.st/Does-anyone-remember-details-of-a-pro-Smalltalk-merger-circa-2013-tp4858715.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Is "Enterprise Pharo" available in PDF?

[Richard Sargent]

Thanks!



--
View this message in context: 
http://forum.world.st/Is-Enterprise-Pharo-available-in-PDF-tp4857121p4857380.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] Is "Enterprise Pharo" available in PDF?

[Richard Sargent]

In looking at http://files.pharo.org/books/enterprisepharo/, I see a link to
get the book in PDF form. ("The full book is available as a free printable
PDF download.") The link takes me to
https://gforge.inria.fr/scm/?group_id=3552, which seems to be the source
code repository.

Is the PDF version available, even as a running CI artefact?




--
View this message in context: 
http://forum.world.st/Is-Enterprise-Pharo-available-in-PDF-tp4857121.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] method return-typing (was Re: Date&Time api)

[Richard Sargent]

Ben Coman wrote
>> On Tue, Aug 18, 2015 at 1:21 AM, Yuriy Tymchuk <

> yuriy.tymchuk@

> > wrote:
>>>
>>> Hi,
>>>
>>> there are some weird things around the data & time API. So time-related
>>> classes are using methods like #asNanoSeconds. And numbers do not
>>> implements
>>> it. But they do implement methods as #nanoSeconds, #milliSeconds,
>>> #seconds
>>> and #asSeconds. Of course "5 nanoSeconds” are nicer than “5
>>> asNanoSeconds”.
>>> Maybe we can do something to maintain polymorphism?
>>>
>>> Uko
> 
> On Wed, Aug 19, 2015 at 3:21 AM, Chris Cunningham
> <

> cunningham.cb@

> > wrote:
>> To, #asNanoSeconds converts the time into the umber of nanosecond that
>> the
>> time represents.
>> #nanoSeconds (and the others) create a duration that is to be added to
>> the
>> time or DateAndTime. The two do not end with the same things 0 and
>> shouldin't.
>>
>> The first tells you how many they represent; the second builds duration.
>>
>> Probably not ideal names - but the intents are definitely different.
>>
>> -cbc
> 
> That is a fine distinction, and relatively hidden from someone reading
> application code.  So the follow up question is how to make such
> distinction visible to an application developer.  It would be nice to
> hover over a message send to get a popup showing the "type" returned
> and messages available.  From time to time I consider what Smalltalk
> might be like where the return-type of a method is specified (i.e.
> only the method return type, still not typing variables). Anyone know
> of a programming language like that?
> 
> Return-typing might facilitate:
>   * Static analysis making a return-type hover popup simple.
>   * Static analysis of cascade message sends.
>   * Definition of global conventions that a particular message always
> returns a particular type, with automatic checking. Runtime violations
> might be logged full-time, or only when running unit tests.  The
> message return-type effectively becomes an interface definition and
> the methods the implementation.
> 
> A return type might be:
> * a class
> * a trait
> * a more narrowly defined "protocol" subset of messages, which might
> help with static analysis for modularisation and minimising the
> bootstrap.
> 
> cheers -ben
> 
> btw, I notice...
>   * Number>>nanoSeconds returns a Duration,
>   * Duration>>nanoSeconds returns an Integer.

If you want to rename anything, rename the instance variable. Keep Smalltalk
readable. As long as it is an English-based language, spell out words in
English. (Similar rules apply regardless of the language one uses to write
Smalltalk applications!)


> Should the latter be renamed #asNanoSeconds, or perhaps #nanos in line
> with its instance variable?  Indeed, perhaps all #asNanoSeconds should
> be renamed #nanos, since its not converting to a NanoSeconds class.
> If its being converted to a raw integer, presumably the context of its
> usage will remain apparent plus the developer will have to
> subsequently mange that.





--
View this message in context: 
http://forum.world.st/method-return-typing-was-Re-Date-Time-api-tp4843929p4844098.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] line endings

[Richard Sargent]

VisualWorks uses CR. I suspect that is because the original Smalltalk-80 did
so. (I don't know what Squeak does. Is it CR, too?)




--
View this message in context: 
http://forum.world.st/line-endings-tp4840829p4841133.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Stack

[Richard Sargent]

Sean P. DeNigris wrote
> 
> Thierry Goubier wrote
>> I consider that subclassing should be used for implementation reuse and
>> not for subtyping.
> That is the GoF position and it makes a lot of sense to me. In fact, I
> think we Smalltalkers suffer from McLuhan's "people become their tools"
> syndrome in that, because the browser makes it easy to view inheritance
> trees, we confuse inheritance with subtyping, creating unnecessary
> coupling. This also adds to the "Smalltalk has no APIs" problem; when only
> subclasses are considered subtypes, one never has to define what is and is
> not the public API; protocols could help here, but have never really been
> fleshed out for this purpose and are a mess right now due to overloading
> with extension method duties.

Definitely +1 to that. One of the things I really like about ENVY (as in VA
Smalltalk) is the fact that applications/packages have formally modelled
prerequisites and the in-image representation of a class also models the
contribution of each extending application. (As opposed to "by convention")

I'm not claiming ENVY is the be all to end all. It has room for improvement.
But it does formally model this particular aspect quite well.





--
View this message in context: http://forum.world.st/Stack-tp4834494p4834964.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Pratt Parsers for PetitParser

[Richard Sargent]

camille teruel wrote
>> On 10 Jun 2015, at 19:11, Chris Cunningham <

> cunningham.cb@

> > wrote:
>> 
>> Inteteresting
>> 
>> On Wed, Jun 10, 2015 at 9:36 AM, Camille <

> camille.teruel@

>   camille.teruel@

> >> wrote:
>> Hello Pharoers and Moosers,
>> 
>> I did a Pratt parser extension for PetitParser.
>> 
>> 
> 
>  
>> @PP Devs: 
>> I had trouble with the PPContext furthestFailure that is taken into
>> account instead of the failures I return, so I had to redefine
>> #parseWithContext: to return the failures I want. The results given by
>> furthestFailure were not very meaningful in my case (the same is true for
>> PPExpressionParser btw). 
>> But I guess it was introduced because it gives good results in other
>> cases. 
>> So would it be possible to change this behavior to let the parser decide
>> if it returns the furthestFailure or the original failure?
>> 
>> The intent behind the furthestFailure is that it give the failure that
>> gets the furthest into the source stream.  It is most useful when there
>> are embedded choice operators in the parser - the original/pre furthest
>> behaviour would return the last failure, which depending on the incoming
>> stream and the order of the choice options could be significantly not
>> useful.
>> 
>> I ran into this when working with the sql parser, which started off with
>> the outer choice of (by memory):
>>^ selectStatement / insertStatement / updateStatement /
>> deleteStatement
>> If I was trying to part a select statement that had an error at the very
>> end of the statement, the parser would return an error talking about how
>> the incoming stream failed in deleteStatement.  Not useful.
>> 
>> I would be saddened if this further failure was not available.
> 
> Yes in that case returning the furthest failure gives better results.
> However, this don’t give meaningful messages in all cases.
> For exemple with the calculator I gave in my previous message, if I parse
> ‘1+’ I want to get ‘expression expected at: 2’ but instead it returns ‘$-
> expected at 2'.
> I’m not proposing to remove this feature but to let parsers decide to use
> it or not.
> Something like (changes in bold): 
> 
> PPParser>>parseWithContext: context
>   | result |
>   context initializeFor: self.
>   result := self parseOn: context.
> 
>   "Return the furthest failure, it gives better results than the last
> failure"
>   (result isPetitFailure and: [ self wantsFurthestFailure and: [ context
> furthestFailure notNil ] ]) 
>   ifTrue: [ ^ context furthestFailure ].
>   ^ result

This screams at me. Why not just delegate to the context and use a context
that returns the preferred failure? e.g. end with:
^context preferredResultFor: result.


>   
> PPParser>>wantsFurthestFailure
>   ^ true
> 
> Like this, one can return the failures he wants.
> 
> PPPrattParser>>wantsFurthestFailure
>   ^ false
> 
> 
> Camille
> 
>> 
>> -cbc





--
View this message in context: 
http://forum.world.st/Pratt-Parsers-for-PetitParser-tp4831456p4831486.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Comments in STON

[Richard Sargent]

Damien Cassou-2 wrote
> Sven Van Caekenberghe <

> sven@

> > writes:
> 
>> I am not so sure we should add that. 
>>
>> The JSON spec explicitly does not allow comments because of fear of abuse
>> (that the comments would be used to add semantic meaning outside the
>> spec).
> 
> 
> really? That's surprising. Comments in configuration files are very
> important. Even more when the configuration files are templates for new
> users.

I think you may have combined two requirements and come up with a "I can
adapt this existing idea to handle both" solution. In my experience, I would
suggest the word "adapt" in that phrase /usually ends up/ being better read
as "pervert".

So, let's step back for a moment and start by clearly and precisely
identifying the actual requirements. As I interpret the foregoing
discussion, there are two.
1) We want the ability to include information in a configuration which can
be used to document, explain, guide those who come after.
2) We want to provide a template configuration that will make it easier for
people to figure out how to create a good configuration.

I will also remind everyone of one thing that seems to be a fundamentally
important aspect of Smalltalk programming: we prefer code over comments. For
example, I came across some unit tests which included comments like "The
result should be blah". Generally, we would write that as "self assert:
result equals: blah". So, let's add this requirement:
3) The best implementation of a "spec" like a configuration will maximize
the DSL capability of Smalltalk.


In my opinion, none of these requirements are well satisfied by adding
comments to the STON syntax.

The first requirement, again in my opinion, is best handled by modelling a
narrative aspect in configurations. I'm not suggestion how that should be
done nor what to call it.

The second requirement seems best satisfied by providing a template
configuration file with the its various aspects specified by some example
content that clearly illustrates the right way to do it.

And the third requirement is satisfied when the modelling of the
configuration formalizes what it is we want it to convey.



> -- 
> Damien Cassou
> http://damiencassou.seasidehosting.st
> 
> "Success is the ability to go from one failure to another without
> losing enthusiasm." --Winston Churchill





--
View this message in context: 
http://forum.world.st/Comments-in-STON-tp4830944p4830990.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Refactoring File Package

[Richard Sargent]

Ben Coman wrote
> On Sat, Jun 6, 2015 at 5:26 PM, Guillermo Polito
> <

> guillermopolito@

> > wrote:
>> Actually we just want to have a kind of split in:
>>
>> - essential
>> - non-essential
> 
> I guess you have scripts outside the image to shrink the image and
> then bootstrap it.  However these are not necessarily visible to
> everyone and I am wondering once the bootstrap goal is achieved you
> will handle the entropy of ongoing development by many others
> accidentally introducing dependencies that breaks the bootstrap?
> 
> Also what I have seen is classes being moved out of their current
> packaging (sorry I forget the details, but I think it was moved out of
> System) into a new top-level package, which I think loses something in
> structure and might pollute the top-level packages.
> 
> So considering the recent discussion of package tags, I wonder if
> somehow we could have a "Bootstrap" tag and realtime critics that
> complain if Bootstrap-tagged-class references any
> non-Bootstrap-tagged-class.  There might even be several levels of
> Bootstrap tags.  This would improve ongoing visibility of the
> bootstrap structure and help the rest of us to not shoot it in the
> foot.

One of the things I really like about ENVY (as found in VA Smalltalk) is
that packages are formally modelled and are distinct from method categories.
(Another is that a method can have multiple categories.) And by formally
modelling packages, one can easily include proper dependency relationships
and more easily detect references to behaviours outside a packages
prerequisites chain.

I realize that is a huge departure from current Squeak and Pharo practice.
But, I hope it's one that will get consideration. (Given all the other first
class modelling you've been adding to Pharo, I think this would be
consistent with the current philosophy!)



> I wonder also if tags might also be extended to method protocols, so
> you can have a method with the "accessors" tag and also the
> "bootstrap" tag, so that even a Bootstrap-tagged-class can be further
> minimised by the methods it needs during bootstrap.  Otherwise I guess
> to minimise the methods in a Bootstrap-tagged-class, later extension
> by another package could not add methods to the "accessors" protocol.
> 
> P.S. I know I do a lot of wondering, and of course divergent thought
> is easier than concrete answers.
> cheers -ben
> 
> 
>>
>> Then the bootstrap will include essential packages at the beginning and
>> non-essential will be just loaded on top.
>>
>> The rationale is: the smaller the kernel, the fastest the bootstrap, and
>> with it the feedback loop we have.
>>
>> That's why I was working on the File abstractions, and splitting some
>> other
>> kernel package.
>>
>> El vie., 5 de jun. de 2015 a la(s) 7:35 p. m., stepharo <

> stepharo@

> >
>> escribió:
>>>
>>> Yes sven but with guille we are working on a really small kernel. So we
>>> can duplicate just the classes we need but I would prefer not
>>> but we can do it. The size is important for us because it takes time to
>>> bootstrap.
>>>
>>> Stef
>>>
>>> Le 5/6/15 19:06, Sven Van Caekenberghe a écrit :
>>> >> On 05 Jun 2015, at 18:43, Guillermo Polito <

> guillermopolito@

> >
>>> >> wrote:
>>> >>
>>> >> The only encoder that makes a bit of noise to me is the ZnByteEncoder
>>> >> that contains a lot of mapping tables for mostly unused encodings
>>> > 67 encoding specifications, each a 128 array. The method constant is
>>> > shared when used.
>>> > In the beginning there were only a couple, one day I added many more,
>>> > some people need them.
>>> > For me, the cost is reasonable.
>>> >
>>> >> (plus methods with metadata to recreate them)...
>>> > That is just two method (which is pretty cool, I love spec based
>>> > programming).
>>> >
>>> >> El vie., 5 de jun. de 2015 a la(s) 6:30 p. m., Sven Van Caekenberghe
>>> >> <

> sven@

> > escribió:
>>> >>
>>> >>> On 05 Jun 2015, at 18:20, stepharo <

> stepharo@

> > wrote:
>>> >>>
>>> >>> Sven
>>> >>>
>>> >>> we were talking about splitting your package into two parts :)
>>> >>> Would you be ok to get the basic encoders in a separate package?
>>> >> Zinc-Character-Encoding is already a separate package, it depends on
>>> >> nothing.
>>> >> Zinc-Resource-Meta is next up (containing URL and Mime-Type).
>>> >> Both are completely independent of any HTTP stuff.
>>> >> All this is by design.
>>> >>
>>> >> You probably mean that you want a separate config ? Right now they
>>> are
>>> >> just a groups.
>>> >>
>>> >>> We were also thinking that NullEncoder could be called AsciiEncoder?
>>> >> Maybe, maybe not, let me think about that a bit.
>>> >>
>>> >>> Stef
>>> >>>
>>> > On 05 Jun 2015, at 18:09, Damien Cassou <

> damien.cassou@

> >
>>> > wrote:
>>> >
>>> >
>>> > Guillermo Polito <

> guillermopolito@

> > writes:
>>> >
>>> >> Well, I made a cleaner implementation at the side with
>>> >>
>>> >> - a simple File object that is a sequen

Re: [Pharo-dev] Null Coalesce Operator?

[Richard Sargent]

abergel wrote
> Hi!
> 
> I perfectly understand the purpose of this method "??”
> Although I do not think this will seriously impact the quality of the code
> being produced, ...

Actually, I would argue it that it would degrade the quality of code. There
is less clarity conveyed by infix operators than by keyword messages, unless
the infix operator is already well known (such as common arithmetic
operators) or somewhat easily guessed (such as #~=). #?? only has meaning if
you already know it from other languages.



> ... I still believe it will not help making code of a better quality.
> Check for the nil value should be banned in my opinion. There are
> well-known techniques to not have to use it (e.g., Null-object pattern).
> 
> Cheers,
> Alexandre
> 
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
>> On May 20, 2015, at 3:19 PM, Aliaksei Syrel <

> alex.syrel@

> > wrote:
>> 
>> Hi,
>> 
>> Null coalesce operator - returns the first not nil operand.
>> http://en.wikipedia.org/wiki/Null_coalescing_operator
>> ;
>> 
>> Adding one simple method to an Object:
>> 
>> ?? anObject
>>  ^ self
>> 
>> and to UndefinedObject:
>> 
>> ?? anObject
>>  ^ anObject
>> 
>> could allow us to write: 
>>  
>> default1 := nil.
>> default2 := nil.
>> default3 := 'foo'.
>> default4 := 'don''t care'.
>> config := default1 ?? default2 ?? default3 ?? default4.
>> 
>> => 'foo' 
>> 
>> I know you don't like to add new methods to an object, but still :)
>>





--
View this message in context: 
http://forum.world.st/Null-Coalesce-Operator-tp4827707p4827911.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Class Comment Template Suggestion

[Richard Sargent]

stepharo wrote
> I have no problem with changing it this is just that we should in 
> general write much better class comments.

This is true for all commentary. :-)

One of the most important things to include in comments and which is usually
omitted is the rationale. Explain why the class exists (it may be obvious in
many cases; but usually not so obvious to an outsider), when and why you
would use the class.

And of course, this doesn't mean we should ignore how to use it.



> Stef
> 
> Le 29/4/15 15:17, Sean P. DeNigris a écrit :
>> The class comment template begins: "For the Class part:  State the name
>> of
>> the class with one line description: For example, I'm xxx the root of the
>> hierarchy of visitor objects."
>>
>> Unlike a traditional CRC card, we are already in a live programming
>> environment with good tools! So the class name is duplicated info (the
>> browser already shows this) which will have to be manually changed on a
>> class rename. Also, the specific example provides an implementation
>> detail
>> duplicated by the class hierarchy tree already shown in the browser. I'd
>> like to change it to: "For the Class part:  State a one line summary. For
>> example, "I represent a paragraph of text.""
>>
>> Any objections?
>>
>>
>>
>> -
>> Cheers,
>> Sean
>> --
>> View this message in context:
>> http://forum.world.st/Class-Comment-Template-Suggestion-tp4822890.html
>> Sent from the Pharo Smalltalk Developers mailing list archive at
>> Nabble.com.
>>
>>





--
View this message in context: 
http://forum.world.st/Class-Comment-Template-Suggestion-tp4822890p4824840.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Roadmap

[Richard Sargent]

Dmitri Zagidulin wrote
> Similar question - are there any roadmap plans to add Dictionary literals
> to Pharo?

Please be careful of complicating the language syntax. Perhaps the better
solution is to improve the optimizer until it can recognize the fact that
the expression really is constant and can inline the generated code.

I had an interesting lesson in this just the other day from Martin McClure.
I had been asking for a feature like VA Smalltalk's "compile-time constant".
I am now convinced that is not the way to go.



> On Mon, Apr 20, 2015 at 1:20 PM, stepharo <

> stepharo@

> > wrote:
> 
>>
>>
>> Le 20/4/15 16:39, Dmitri Zagidulin a écrit :
>>
>> I would love to see two things in Pharo 5:
>>
>>  1) Fix for mouse scrolling (at least on Mac OS X, though I think it does
>> the same on Linux etc) in the class pane. While mouse-scrolling (either
>> via
>> a mouse wheel or two-finger scrolling on the touchpad) through the
>> classes,
>> the focus frequently and erratically jumps to the package pane, and the
>> package pane starts scrolling instead. The focus also sometimes jumps
>> when
>> you reach the end of the class list (and, again, the package pane starts
>> scrolling instead).
>>
>>
>> Yes
>>
>>
>>  2) A button in the debugger that copies the error message to the
>> clipboard (you can sort of do it currently by editing the title of the
>> error window, but that's really awkward).
>>
>>
>> it should be easy to do.
>>
>>
>>  I also have a question. Are there currently any roadmap plans for
>> namespaces or modules for Pharo? I saw a brief discussion about it a few
>> years back (http://forum.world.st/Pharo-and-Namespaces-td4636635.html ),
>> and wanted to see if it's still on the table.
>>
>>
>> Yes but not for Pharo 50.
>>
>> Stef
>>
>>
>>
>>
>> On Mon, Apr 20, 2015 at 2:58 AM, stepharo <

> stepharo@

> > wrote:
>>
>>> Hi
>>>
>>> if you have suggestions please let us know. Now usually suggestions
>>> often
>>> comes with time allocation ;)
>>> We have definitively a list of points we want to see addressed.
>>>
>>> Stef
>>>
>>> Le 19/4/15 23:19, Torsten Bergmann a écrit :
>>>
>>>  Do we have a roadmap for Pharo 5 already?




>>>
>>>
>>
>>





--
View this message in context: 
http://forum.world.st/Roadmap-tp4820561p4820934.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Duration year

[Richard Sargent]

Maximiliano Taborda wrote
> Hi all.
> 
> The same examples using Chaltén:
>  February twentyninth, 2012 next: 1 yearMeasure.   "=> February 28th,
> 2013"

This I don't get. Why would  + 1 day + 1 year ever not be
March 1st? ~75% of the time it would be, but ~25% it would be a day less?


>  March first, 2011 next: 1 yearMeasure.  "=> March 1st, 2012"
>  March first, 2011 next: 12 monthsMeasure. "=> March 1st, 2012"
> 
> Hilaire, In Chaltén a year is a year so you don't need to care about of
> the
> number of days in it.
> 
> Regards.
> Maxi
> 
> 
> 2014-12-02 16:37 GMT-03:00 Chris Cunningham <

> cunningham.cb@

> >:
> 
>> GenericYear does this.  The generic Year will take
>>'2/29/2000' asDate + 1 year "=> 28 February 2001"
>> In other words, we want it at the same time next year; more importantly
>> the same month and close to what we have now.
>> Also:
>>'3/1/2001' asDate - 1 year "=> 1 March 2000"
>> Still, same month - we want to be at the beginning of the month the
>> previous year.
>>
>> Basically, my idea (and, more importantly, what I expect - hence my code)
>> is that I want to pretend that we do have a field-based representation
>> and
>> make it work that way.  except better (since there is no 2/29/2001).
>>
>> > Ej, which one of the followings is OK?
>> > '2011-03-01' asDate + 1 year "=> 2012-02-29"
>>
>> Well, I have a bug here.  That needs to be fixed.
>>
>> -cbc
>>
>>
>> On Tue, Dec 2, 2014 at 8:34 AM, Sean P. DeNigris <

> sean@

> >
>> wrote:
>>
>>> Esteban A. Maringolo wrote
>>> > Ej, which one of the followings is OK?
>>> > '2012-02-29' asDate + 1 year  "=> 2013-02-28"
>>> > '2011-03-01' asDate + 1 year "=> 2012-02-29"
>>>
>>> One solution (just ignore the source ha ha) -
>>>
>>> http://msdn.microsoft.com/en-us/library/system.datetime.addyears%28v=vs.110%29.aspx
>>>
>>>
>>>
>>> -
>>> Cheers,
>>> Sean
>>> --
>>> View this message in context:
>>> http://forum.world.st/Duration-year-tp4791727p4793656.html
>>> Sent from the Pharo Smalltalk Developers mailing list archive at
>>> Nabble.com.
>>>
>>>
>>





--
View this message in context: 
http://forum.world.st/Duration-year-tp4791727p4813662.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] About Matrix API access

[Richard Sargent]

stepharo wrote
> ...
> | matrix23 |
> matrix23 := Matrix rows: 3 columns: 2.
> matrix23 at: 1 at: 1 put: 11.

What? #at:at:put:? That *will* cause errors. The "at"s are effectively
anonymous keywords.

I hope the API can still be changed. e.g. #atRow:column:put: and possibly
also #atColumn:row:put:.



Thaks,
Richard



--
View this message in context: 
http://forum.world.st/About-Matrix-API-access-tp4805746p4806237.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] ||

[Richard Sargent]

Levente Uzonyi-2 wrote
> On Tue, 3 Feb 2015, Marcus Denker wrote:
> 
>>
>>   On 03 Feb 2015, at 09:17, Marcus Denker <

> marcus.denker@

> > wrote:
>> 
>>
>>   On 02 Feb 2015, at 21:47, Eliot Miranda <

> eliot.miranda@

> > wrote:
>> 
>> Hi All,
>>     code as in the double bars forming the end of block arguments and the
>> beginning of block temporaries in
>> 
>> 
>> This is fixed in Pharo4 (I think we did that in Pharo3 already):
>> 
>> I should search the issue in the issue tracker… it seems to be Pharo4, so
>> just 1296 closed issues to check there…
>> I will search for it.
>> 
>> Another question: In the code I saw. ReadOnlyVariableBinding. I removed
>> that in Pharo relatively early as it was not used:
>> half of the classes were stored that binding (old ones) all newer ones
>> where just associations.
>> The code to make a binding "read only" was never called.
>> 
>> Is this now used in Squeak? Is it worth the complexity?
> 
> Squeak doesn't use ReadOnlyVariableBinding anymore. The bindings of 
> classes are instances of the ClassBinding class.
> Without using separate class it's a bit cumbersome (and less OO) to decide 
> if an assignment to a global variable should be allowed or not. E.g.:
> 
>   Foo := 1.
> 
> should work if Foo is a global, but not a behavior. It should raise an 
> error if it's a behavior.

I have mixed feelings about that. In most Smalltalks one can write something
like the following and expect it to work.

| original |
original := SomeClass.
[SomeClass := SomeReplacementClass.
... some code involving SomeClass (typically a passed in Block) ...
] ensure: [SomeClass := original]

That is, the name of the thing is not the thing itself.

Of course, as long as one could write /Smalltalk at: #SomeClass put:
SomeReplacementClass/, it would still be possible to achieve the same
effect. (And of course, "Smalltalk" could be any namespace.)



> Levente
> 
>> 
>> Marcus
>> 
>>





--
View this message in context: http://forum.world.st/-tp4803298p4803783.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Tools for automatic recognition of Design Patterns

[Richard Sargent]

Nevena Milojkovic wrote
> Can anyone suggest me tool for automatic design patterns detection in
> Smalltalk?

The rewrite tool in the Refactoring Browser has the potential, but I
strongly suspect the problem is intractable.

By the way, the rewrite tool is powerful but difficult to figure out and
use, even when you can find the documentation for it.




--
View this message in context: 
http://forum.world.st/Tools-for-automatic-recognition-of-Design-Patterns-tp4802777p4802789.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Object>>logCr ?

[Richard Sargent]

abergel wrote
> ...
> why printString is used and not asString?
> ...

As stepharo pointed out, #asString is a conversion method. It is often
misused and misrepresented (see especially Java's toString() method).

It is important to clearly distinguish purpose, so we often see
#printString, #displayString, #storeString, as well as #asString.

With #asString, one could envision saying "1 asString asNumber" and
recreating the original object. That is what we expect from conversion
methods (oversimplified, but I think you get the point).

Most objects cannot do that.

 #printString is meant to portray the object in sufficient detail that one
can recognize it, but not necessarily recreate it. (typically of use to a
programmer, but not necessarily only to programmers)

 #displayString is meant to provide a suitable representation of an object
for a user of the system. (typically an application user more so than a
programmer, but really for anybody).

 And #storeString is meant to provide a representation that would allow
creation of an equivalent object when evaluated.


Back to your original question. One could override Object's implementation
of #logCr in String to do as you would like (it seems reasonable enough,
although you would probably want to ensure Symbol works differently from
String). Alternatively, one could (and perhaps should) define a #logString
with the default implementation using #printString and subclass that method
where appropriate. e.g. #printString often truncates long collections with a
"...". #logString probably would not do that.




--
View this message in context: 
http://forum.world.st/Object-logCr-tp4799595p4800051.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] What is the limit

[Richard Sargent]

EstebanLM wrote
>> On 24 Nov 2014, at 23:48, 

> phil@

>  wrote:
>> 
>> On mobile, large apps are not staying installed for long as they are all
>> competing for the always too small space.
>> 
>> If say Twitter will do with is huge size, other apps will be compared to
>> it. Which means that a 30 mégas app us a monster asking for removal.
>> 
> the average size of any app in iPhone is around 25m (or it was in 2012,
> nowadays should be more), so I hardly believe that :)
> 
> I have a "flashlight" app installed. It has one feature: to turn on the
> light. It's total storage on my S3 is 26.3 MB. ... for a freaking
> flashlight!
> 
> Amazon app: 67 MB
> Costco: 26 MB
> Facebook: 208 MB!!
> Google Play Books (with few books): 32 MB
> Google Search: 81 MB
> 
> I agree there is value in a small footprint, but not that much. As others
> have said: Moore's law.
> 
> 
> Esteban
> 
>> I rooted my phone to be able to remove vendor apps in order to get some
>> more space.
>> 
>> Phil
>> 
>> Le 24 nov. 2014 22:31, "kilon alios" <

> kilon.alios@

>   kilon.alios@

> >> a écrit :
>> I have an OS (Yosemite) thats takes 5 out my 8 GB of Ram. Google Chrome
>> with opened 20 tabs that consumes around 1 GB of Ram. Games that eat Ram
>> like peanuts and I do 3d graphics with blender which also can consume GBs
>> like no tommorow. Music productions was not much diffirent either.  I
>> watch movies which are several GBs each. I have 1 TB drive its already
>> half full (mainly because of movies). 
>> 
>> 32 mb is nothing. XCode with an empty project cosumes 130 MB. Dont forget
>> that it loads no libraries like Pharo and definetly is no live coding
>> enviroment. 
>> 
>> Pharo consumes around 80MBs
>> 
>> Emacs with zero guis still consumes 40mbs. 
>> 
>> Small is not beautiful its irrelevant.   
>> 
>> Unless you are on a platform that has real problem with sizes. 
>> 
>> On Mon, Nov 24, 2014 at 10:29 PM, Hilaire <

> hilaire@

>   hilaire@

> >> wrote:
>> Pharo 1.4 image = 15MB
>> Pharo 3 image = 22MB
>> Pharo4 image = 32MB
>> 
>> Don't know about Pharo 2.0 as, skip it.
>> 
>> Is there a limit?
>> 
>> Hopefully I gave up on the idea of tablet use but aren't we loosing the
>> sight on small is beautiful?
>> 
>> Hilaire
>> 
>> --
>> Dr. Geo - http://drgeo.eu ;
>> iStoa - http://istoa.drgeo.eu ;
>> 
>> 
>>





--
View this message in context: 
http://forum.world.st/What-is-the-limit-tp4792049p4792243.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Can anyone provide me with clear, complete, and detailed instructions for loading PetitParser into Pharo 3.0?

[Richard Sargent]

kurs.jan wrote
> Hi All,
> 
> Sorry for a late reply, here is the latest status with PetitParser and
> Pharo (tested on Pharo3):
> 
> "Configuration should be loaded like this:"
> Gofer new smalltalkhubUser: 'Moose' project: 'PetitParser';
> configurationOf: #PetitParser; load.
> 
> "Minimal set of parsers to use petit parser:"
> ConfigurationOfPetitParser project stableVersion load: 'Core'.
> ConfigurationOfPetitParser project stableVersion load: 'Tests'.
> 
> "All the petit parser suite:"
> ConfigurationOfPetitParser loadDevelopment.
> 
> Please, let me know if you have any issues/requirements.

Thank you, Jan! That worked perfectly.

I did notice a large number of warnings and errors in the Transcript. Many
of them we resolved later in the loading, just being load order
dependencies. But many of them appear to be genuine errors. Are they
expected?

The following is a distillation of the messages in the Transcript showing
these issues. Quite a number of them were resolved; I have annotated them
with "***Resolved by later load***" at the end of the line.


PPMemento>>position: (position is Undeclared) 
PPMemento>>position (position is Undeclared) 
PPMemoizedParser>>reset: (stream is Undeclared) 
PPMemoizedParser>>parseOn: (stream is Undeclared) 
PPMemoizedParser>>parseOn: (stream is Undeclared) 
PPMemoizedParser>>parseOn: (stream is Undeclared) 
PPMemoizedParser>>parseOn: (stream is Undeclared) 
PPMemoizedParser>>parseOn: (stream is Undeclared) 
PPMemoizedParser>>parseOn: (stream is Undeclared) 
PPMemoizedParser>>parseOn: (stream is Undeclared) 
PPMemoizedParser>>parseOn: (stream is Undeclared) 
PPMemoizedParser>>parseOn: (stream is Undeclared) 
JavaParserTest>>createContext:(context is shadowed)
PPMemoizingIslandTest>>testMemo(context is shadowed)
PPSmalltalkParser>>buildMethod:(pragma is shadowed)
Loaded -> PetitParser-JanKurs.253 ---
http://smalltalkhub.com/mc/Moose/PetitParser/main/ --- cache

GLMBrowser>>close (GLMBrowserClosed is Undeclared) ***Resolved by later
load***
GLMCompositePresentation>>accumulator (GLMAccumulator is Undeclared)
***Resolved by later load***
GLMCompositePresentation>>actionList (GLMActionListPresentation is
Undeclared) ***Resolved by later load***
GLMCompositePresentation>>diff (GLMDiffPresentation is Undeclared)
***Resolved by later load***
GLMCompositePresentation>>dropDownList (GLMDropDownListPresentation is
Undeclared) ***Resolved by later load***
GLMCompositePresentation>>dynamic (GLMDynamicPresentation is Undeclared)
***Resolved by later load***
GLMCompositePresentation>>finder (GLMFinder is Undeclared) ***Resolved by
later load***
GLMCompositePresentation>>list (GLMListPresentation is Undeclared)
***Resolved by later load***
GLMCompositePresentation>>morph (GLMMorphPresentation is Undeclared)
***Resolved by later load***
GLMCompositePresentation>>smalltalkCode (GLMSmalltalkCodePresentation is
Undeclared) ***Resolved by later load***
GLMCompositePresentation>>spec (GLMSpecPresentation is Undeclared)
***Resolved by later load***
GLMCompositePresentation>>table (GLMTablePresentation is Undeclared)
***Resolved by later load***
GLMCompositePresentation>>tabulator (GLMTabulator is Undeclared) ***Resolved
by later load***
GLMCompositePresentation>>text (GLMTextPresentation is Undeclared)
***Resolved by later load***
GLMCompositePresentation>>tree (GLMTreePresentation is Undeclared)
***Resolved by later load***
GLMCompositePresentation>>wrapper (GLMWrapper is Undeclared) ***Resolved by
later load***
GLMPresentation>>windowIsClosing (GLMBrowserClosing is Undeclared)
***Resolved by later load***
Loaded -> Glamour-Core-TudorGirba.285 ---
http://smalltalkhub.com/mc/Moose/Glamour/main/ --- cache

GLMSmalltalkCodePresentation>>defaultSelectionActions (GLMUIThemeExtraIcons
is Undeclared) ***Resolved by later load***
GLMSmalltalkCodePresentation>>defaultSelectionActions (GLMUIThemeExtraIcons
is Undeclared) ***Resolved by later load***
Loaded -> Glamour-Presentations-TudorGirba.165 ---
http://smalltalkhub.com/mc/Moose/Glamour/main/ --- cache

GLMExamplesBrowser>>exampleIn: (GLMUIThemeExtraIcons is Undeclared)
***Resolved by later load***
GLMBasicExamples>>browserWithToolbar (GLMUIThemeExtraIcons is Undeclared)
***Resolved by later load***
GLMBasicExamples>>morphIcons (GLMUIThemeExtraIcons is Undeclared)
***Resolved by later load***
GLMBasicExamples>>multipleActions (GLMUIThemeExtraIcons is Undeclared)
***Resolved by later load***
GLMBasicExamples>>populatePortAction (GLMUIThemeExtraIcons is Undeclared)
***Resolved by later load***
GLMBasicExamples>>roassalPainting (RTMondrianViewBuilder is Undeclared)
***Resolved by later load***
GLMBasicExamples>>simplePager (GLMPager is Undeclared) ***Resolved by later
load***
GLMBasicExamples>>smalltalkCode (GLMUIThemeExtraIcons is Undeclared)
***Resolved by later load***
GLMBasicExamples>>smalltalkCode (GLMUIThemeExtraIcons is Undeclared)
***Resolved by later load***
GLMBasicExamples>>tableWithIcons (GLMUIThemeExtraIcon

Re: [Pharo-dev] Can anyone provide me with clear, complete, and detailed instructions for loading PetitParser into Pharo 3.0?

[Richard Sargent]

Paul DeBruicker wrote
> If ConfigurationOfPetitParser is loaded in your image you should be able
> run the following code in a workspace to load the 'Core' metacello group:
> 
> ConfigurationOfPetitParser project stableVersion load: 'Core'
> 
> 
> I'm not sure of the canonical location of the ConfigurationOfPetitParser
> though, as I don't use it,. 

Thanks, Paul. The Configuration Browser is pre-configured with three
repository locations. I was able to find PetitParser (TudorGirba.43) on the
ss3 repository. Loading Core alone worked.

That still leaves the question of loading the PetitParser UI stuff and its
prerequisites.




--
View this message in context: 
http://forum.world.st/Can-anyone-provide-me-with-clear-complete-and-detailed-instructions-for-loading-PetitParser-into-Pha-tp4786556p4786994.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Can anyone provide me with clear, complete, and detailed instructions for loading PetitParser into Pharo 3.0?

[Richard Sargent]

Sean P. DeNigris wrote
> If you don't need the UI, just load the 'Core' group and you should be
> fine.

Thanks for replying, Sean. Unfortunately, I don't know how to process your
answer. What actions do I need to do in what window or what expressions do I
need to evaluate to achieve this?

And likewise, if I do want to load the UI, what do I need to do?



Thanks,
Richard




--
View this message in context: 
http://forum.world.st/Can-anyone-provide-me-with-clear-complete-and-detailed-instructions-for-loading-PetitParser-into-Pha-tp4786556p4786966.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] Can anyone provide me with clear, complete, and detailed instructions for loading PetitParser into Pharo 3.0?

[Richard Sargent]

I appear to have found .43 of ConfigurationOfPetitParser, but it seems to
want Glamour, and Glamour seems to want other stuff ...

What do I have to load, from where, in what order?


Thanks,
Richard




--
View this message in context: 
http://forum.world.st/Can-anyone-provide-me-with-clear-complete-and-detailed-instructions-for-loading-PetitParser-into-Pha-tp4786556.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

[Richard Sargent]

Ben Coman wrote
> Richard Sargent wrote:
>> Eliot Miranda-2 wrote
>>> On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent <
>> 
>>> richard.sargent@
>> 
>>>> wrote:
>>>> One of the best things about Smalltalk is how easily we can say what we
>>>> mean. I think you would be better off creating a method named something
>>>> like
>>>> #hasSameEffectAs: to answer what you are presently using #= to do, and
>>>> change #= to answer the, in my opinion, more sensible "is the same as"
>>>> that
>>>> we conventionally think of #= meaning.
>>>>
>>> But that's the point.  #= has to mean something and having it mean #==
>>> isn't useful, so one has to choose some value-based semantic for
>>> CompiledMethod>>#= and the one that's there is useful.  Defining what #=
>>> means for some value type is far easier than defining what it might mean
>>> for something as complex as a CompiledMethod.  The definition in
>>> Squeak/Pharo has been useful to me in implementing a closure-based
>>> system,
>>> so I'm unapologetic about the current definition.  It is a good one but
>>> it
>>> doesn't preclude defining others.
>> 
>> An interesting response. You ignored the point that e.g.
>> #hasSameEffectAs:
>> provides greater clarity and add an argument against something I didn't
>> say.
>> 
>> I also don't think defining equality for a CompiledMethod is particularly
>> difficult. If I were to recompile a method's source code, I would get a
>> new
>> instance of a CompiledMethod that would, in my opinion, be equal to the
>> one
>> already installed in the class (and perhaps cached in the VM's
>> optimizations). So one would be able to say that we would not replace an
>> existing CompiledMethod with an equal one. The current implementation of
>> #=
>> has no such characteristic, since it proclaims a CompiledMethod named #a
>> to
>> be equal to one named #z.
>> 
> 
> @Richard
> 
> That doesn't seem to be a good example for what your trying to say.
> Given...
> 
> [1] SomeClass>>a "original instance"
>   ^1
> 
> [2] SomeClass>>a "recompiled instance"
>   ^1
> 
> [3] SomeClass>>z
>   ^1
> 
> ...you seem to be saying that its useful to know if [1]=[2],
> but imply that is invalidated by [2]=[3] ?
> 
> But [1]=[2] remains true, and just as useful for your example.

Ben, I believe you are correct. I did not think deeply enough about how
using #= would work. In retrospect, it looks like my hypothesized scenarios
would not be problematic.

But I will stand by my argument about naming methods. The philosophical
technique Reductio ad Absurdum will be useful here.

If I began a method declaration as follows, everyone would agree it was bad.
fred: another
"Answer whether I have the same effect as @another."

I believe almost everyone would agree the mistake in that is that the
comment should be unnecessary because the method name should explain its
purpose.


One of the best heuristics I have ever encountered for naming things is to
start by "explaining to a colleague" (perhaps an imaginary one) what the
thing does, then strip out every word which does not affect the meaning.
[This last step would almost certainly prevent the inclusion of phrases like
"when executing" in a CompiledMethod method, in my opinion.]



> @Max
> 
> I guess to call it a bug, you bumped into a different use case
> where [2]=[3] is problematic. Can you describe that?
> 
> 
> cheers -ben
> 
> 
>> The blue book say #= means "Answer whether the receiver and the argument
>> represent the same component." The current implementation does so only
>> for
>> some, in my opinion, counter-intuitive definition of "same component".
>> 
>> 
>> 
>> 
>> --
>> View this message in context:
>> http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784779.html
>> Sent from the Pharo Smalltalk Developers mailing list archive at
>> Nabble.com.
>> 
>>





--
View this message in context: 
http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4785205.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

[Richard Sargent]

Eliot Miranda-2 wrote
> On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent <

> richard.sargent@

>> wrote:
>> One of the best things about Smalltalk is how easily we can say what we
>> mean. I think you would be better off creating a method named something
>> like
>> #hasSameEffectAs: to answer what you are presently using #= to do, and
>> change #= to answer the, in my opinion, more sensible "is the same as"
>> that
>> we conventionally think of #= meaning.
>>
> 
> But that's the point.  #= has to mean something and having it mean #==
> isn't useful, so one has to choose some value-based semantic for
> CompiledMethod>>#= and the one that's there is useful.  Defining what #=
> means for some value type is far easier than defining what it might mean
> for something as complex as a CompiledMethod.  The definition in
> Squeak/Pharo has been useful to me in implementing a closure-based system,
> so I'm unapologetic about the current definition.  It is a good one but it
> doesn't preclude defining others.

An interesting response. You ignored the point that e.g. #hasSameEffectAs:
provides greater clarity and add an argument against something I didn't say.

I also don't think defining equality for a CompiledMethod is particularly
difficult. If I were to recompile a method's source code, I would get a new
instance of a CompiledMethod that would, in my opinion, be equal to the one
already installed in the class (and perhaps cached in the VM's
optimizations). So one would be able to say that we would not replace an
existing CompiledMethod with an equal one. The current implementation of #=
has no such characteristic, since it proclaims a CompiledMethod named #a to
be equal to one named #z.

The blue book say #= means "Answer whether the receiver and the argument
represent the same component." The current implementation does so only for
some, in my opinion, counter-intuitive definition of "same component".




--
View this message in context: 
http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784779.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

[Richard Sargent]

Eliot Miranda-2 wrote
> I responded...

I have to disagree with your recommendation. You say that you intend #= to
mean "has the same effect as" rather than "is the same as". 

One of the best things about Smalltalk is how easily we can say what we
mean. I think you would be better off creating a method named something like
#hasSameEffectAs: to answer what you are presently using #= to do, and
change #= to answer the, in my opinion, more sensible "is the same as" that
we conventionally think of #= meaning.


$0.02 worth and worth everything you paid for it. :-)
Richard




--
View this message in context: 
http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784771.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Headless mode loss of focus under windows 7

[Richard Sargent]

Blondeau Vincent wrote
> ... at each execution of pharo, I lose focus from the window where I was
> currently working ...

If you watch closely, Pharo */is/* opening a window, and closing it again
immediately. This really requires a change in Pharo, to not open the window
in the first place.




--
View this message in context: 
http://forum.world.st/Headless-mode-loss-of-focus-under-windows-7-tp4770846p4770860.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Doubt in Pharo

[Richard Sargent]

harshit wrote
> So I was creating this dictionary for column at the instance side
> initialization of Employee.
> 
> My instructor suggested to do that in class side initialization,
> 
> My Doubts are:
> 
> 1. Why should we do class side initialization instead of instance side
> initialization.
> 
> 2. Could you please refer me to the link which explains how to do class
> side initialization. Because when I do Employee new, I see only instance
> side initialization is being called.

This comes down to the distinction between class and instance. As you know,
instance-side functionality relates to how individual instances behave while
class-side functionality related to how /all/ instances behave. In this
case, the relational mapping rules are not going to differ from one instance
to another. That is why your instructor advised you to set that up using
class-side behaviour.

If you aren't that familiar with Smalltalk - compared to C-derived languages
like Java - it may be hard to get really and truly adapted to the meaning of
"everything is an object". In this case, you have a number of classes which
represent objects mapped to a relational database, so it makes sense that
each such class is responsible for defining what that mapping is. (Although,
one could argue that proper decoupling of layers moves the responsibility of
knowing how to map the data from the individual classes to some other
objects.)


As far as doing class-side initialization, it is simply a matter of sending
the right messages to the classes at the right time. For example, you might
have a Employee class>>#setUpRelationalMappingRules method defined. Before
you can replicate the data between Smalltalk and SQL, you need to execute
that method. 

You have choices in terms of when you actually do it. 
- There is "lazy initialization" in which the initialization is done at the
last possible instant. But this incurs an overhead in that every mapping
occurrence requires the check.
- There is "application start up initialization" in which the initialization
is done early, as part of starting the application. For example, when you
connect to the database, you can initialize the mapping rules.
- There is "class loading initialization" in which the initialization is
done when you actually load the code into the image. This is typically
controlled by a class-side method called #initialize. The code loading
frameworks may execute the method automatically for you. I find too many
"corner cases" with this technique and I prefer explicit behaviours rather
than implicit ones.

The "application start up initialization" is my preferred approach. If you
imaging the UML of an application, you would have a package for your model
code, another for your persistence mechanism, and a third for your
"application". This is grossly simplified, of course. The application
package has dependencies on the other two packages, but they have no
dependencies on any of the others. In this sense, you are using the
application to tie together the model and the persistence mechanism of your
choice. At start up, you "configure" the persistence mechanism by explicitly
invoking the appropriate methods to set up the server connection, the
mapping rules, and anything else your choice of persistence requires.




--
View this message in context: 
http://forum.world.st/Doubt-in-Pharo-tp4769465p4769668.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] How to get started with Git and Pharo?

[Richard Sargent]

Sven Van Caekenberghe-2 wrote
> The current source code format in git is cool, but can you manage a merge
> or diff like that, with all the different parts scattered over 10s, 100s
> of files, with no matter what tool ? Apart from the fact that such bigger
> merge is always very difficult, no other tools will support our world
> view, ever. 
> 
> ...
> 
> I don't want to sound too negative, I just don't belief it will actually
> make that much difference.

I've seen the work that Dale's done with tODE. Can you manage a merge with
so many files? Yes, without a doubt. Does git do an excellent job of merging
and differencing? Absolutely.


In terms of making a difference, I'm of the opinion that git provides
something modern, universal, and comparable to ENVY (which I have used for
most of the last 20 years and admire immensely).

Are there more important things to do? Without a doubt. Is this worth too
little to bother with? Absolutely not. git will facilitate configuration
management (not just versionning) and will also greatly facilitate
cross-dialect compatibility. The ability to easily pick up an offering from
one Smalltalk and fork it with small changes for another dialect will be
nirvana for many of us.





--
View this message in context: 
http://forum.world.st/How-to-get-started-with-Git-and-Pharo-tp4765096p4765178.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] about ~=

[Richard Sargent]

Esteban A. Maringolo wrote
> If one thing confuses people in that realm is non arithmetic precedence:
> Eg. 2 + 3 * 4 = 20 instead of the "expected" 14.
> 
> And we're not going to change that either. It's not worthy, and I
> doubt if it is possible at all.

I'm probably late to the party with this reply. The primary reason for not
changing this is that it would be incorrect. It comes down to intrinsic
versus extrinsic meaning. A multiple operator has an intrinsic meaning: it
means multiple. But a message name does not have intrinsic meaning (other
than it is a good idea to have the name represent what it does). The meaning
of a message is determined by the receiver. e.g. if PetitParser defines #*
to mean "0 or more repetitions", what happens when someone has decided that
it should be evaluated before #+?

Message sending precedence can only be defined in terms of the type of
message: unary, binary (or infix), and keyword, since the interpretation of
the message is the receiver's responsibility, not the compiler's.




--
View this message in context: http://forum.world.st/about-tp4764892p4765070.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.