Re: [Pharo-dev] [Pharo-users] About strange email related to smalltalkhub read-only on squeak-dev
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
Re: [Pharo-dev] [Pharo-users] [Pharo-Launcher] call for tests on Windows
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
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
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* >> http://www.cnrs.fr; >> >> >> >> *Web:* *http://guillep.github.io* 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* http://www.cnrs.fr; *Web:* *http://guillep.github.io* 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* > http://www.cnrs.fr; > > > > *Web:* *http://guillep.github.io* 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
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.?
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
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
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?
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
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@ > mailto: > 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.
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.
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.
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?
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
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
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?
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 the
[Pharo-dev] GemStone/S 3.3.1 released
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
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
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?
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
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:
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)
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 > of a custom VM for his Pharo bootstrap. But
Re: [Pharo-dev] Disable assertions (design by contract)
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
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)
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))
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
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?
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?
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?
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: DateTime api)
Ben Coman wrote On Tue, Aug 18, 2015 at 1:21 AM, Yuriy Tymchuk lt; yuriy.tymchuk@ gt; 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 lt; cunningham.cb@ gt; 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... * NumbernanoSeconds returns a Duration, * DurationnanoSeconds 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
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
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
camille teruel wrote On 10 Jun 2015, at 19:11, Chris Cunningham lt; cunningham.cb@ gt; wrote: Inteteresting On Wed, Jun 10, 2015 at 9:36 AM, Camille lt; camille.teruel@ lt;mailto: camille.teruel@ gt; wrote: Hello Pharoers and Moosers, I did a Pratt parser extension for PetitParser. snip @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): PPParserparseWithContext: 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. PPParserwantsFurthestFailure ^ true Like this, one can return the failures he wants. PPPrattParserwantsFurthestFailure ^ 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
Damien Cassou-2 wrote Sven Van Caekenberghe lt; sven@ gt; 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
Ben Coman wrote On Sat, Jun 6, 2015 at 5:26 PM, Guillermo Polito lt; guillermopolito@ gt; 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 lt; stepharo@ gt; 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 lt; guillermopolito@ gt; 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 lt; sven@ gt; escribió: On 05 Jun 2015, at 18:20, stepharo lt; stepharo@ gt; 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 lt; damien.cassou@ gt; wrote: Guillermo Polito lt; guillermopolito@ gt; writes: Well, I made a cleaner implementation at the side with - a simple File object that is a sequential File as we all know - a binary File stream on top of it that is composable with Zn encoders and other decorators - a new interface to access Stdio streams that's really good news Guillermo. Yes it is (need time to look at this in detail) Is it ok to make File reading depend on Zinc? This sounds strange. Wouldn't that make
Re: [Pharo-dev] Null Coalesce Operator?
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 lt; alex.syrel@ gt; wrote: Hi, Null coalesce operator - returns the first not nil operand. http://en.wikipedia.org/wiki/Null_coalescing_operator lt;http://en.wikipedia.org/wiki/Null_coalescing_operatorgt; 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] Roadmap
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 lt; stepharo@ gt; 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 lt; stepharo@ gt; 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
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 February 28th + 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 lt; cunningham.cb@ gt;: 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 lt; sean@ gt; 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
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 ats 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] ||
Levente Uzonyi-2 wrote On Tue, 3 Feb 2015, Marcus Denker wrote: On 03 Feb 2015, at 09:17, Marcus Denker lt; marcus.denker@ gt; wrote: On 02 Feb 2015, at 21:47, Eliot Miranda lt; eliot.miranda@ gt; 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
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] ObjectlogCr ?
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
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 lt; kilon.alios@ lt;mailto: kilon.alios@ gt; 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 lt; hilaire@ lt;mailto: hilaire@ gt; 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 lt;http://drgeo.eu/gt; iStoa - http://istoa.drgeo.eu lt;http://istoa.drgeo.eu/gt; -- 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?
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.
Re: [Pharo-dev] Can anyone provide me with clear, complete, and detailed instructions for loading PetitParser into Pharo 3.0?
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.
[Pharo-dev] Can anyone provide me with clear, complete, and detailed instructions for loading PetitParser into Pharo 3.0?
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] CompiledMethodhash can produce clashes
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] SomeClassa original instance ^1 [2] SomeClassa recompiled instance ^1 [3] SomeClassz ^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] CompiledMethodhash can produce clashes
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] CompiledMethodhash can produce clashes
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] Headless mode loss of focus under windows 7
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
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] about ~=
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.
Re: [Pharo-dev] How to get started with Git and Pharo?
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.
