February 2019 - Pharo-users

Re: [Pharo-users] Learn Pharo - Not Working

by magicspeller

Richard70NL wrote > For me it works, but what you can also try is: > 1) Click the menu Tools -> Playground > 2) Type: ProfStef go. > 3) Right click what you just typed and click "Do It" > > BTW, I'm also new with Pharo (not with programming) and I really enjoy the > book at http://books.pharo.org/pharo-by-example/. Hi Richard, Like you, I have a programming background, but Pharo and Smalltalk are quite a new experience. I downloaded /Pharo By Example/ but haven't gotten around to reading any of it yet. Thank you for the Playground suggestion! That's a great idea, and it works really well. That means I should be able to go back to the 64-bit version. Can you tell me why you don't have to select "ProfStef go." before right clicking it. I had gotten the impression that to execute any Smalltalk statement you always have to select it first. Thanks again, Keith -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 3, 2019

Re: [Pharo-users] favorite way to migrate from mczs to git?

by Paul DeBruicker

Thanks Sean. I get a couple different errors, depending on which Pharo I'm using. I had more time today and for 7.0, I think I fixed it. I don't think the #ignoredFileNames: method was working because when I added corrupted MCZs as in the example pasted below, it seems to continue to try to analyze those files when running #allAuthors and hit encoding errors. Skipping the #allAuthors send and just running the #fastImportCodeToDirectory:initialCommit:to: code gives the same encoding errors. Changing GitMigration>>#versions to versions versionsCache ifNil: [ | versions | versions := OrderedCollection new. self versionsWithPackageNames do: [ :quad | | fileName | fileName := quad last. (ignoredFileNames includes: (fileName allButLast: 4)) ifFalse: [ versions add: (self versionFromFileNamed: quad last) ] ] displayingProgress: [ :quad | 'Loading versions metadata... ' , quad last ]. versionsCache := versions ]. ^ versionsCache fixes my problem, but I can't seem to create a PR that doesn't include every line of every file as having changed. In 6.1 git-migration doesn't have a problem with the bad MCZs but instead gives an "Empty message requested" error when doing the #fastImportCodeToDirectory:initialCommit:to: In 6.0 it gives a DNU for GitMigrationMemoryTreeGitRepository>>#writeGitFileTreeProperties: (I made an issue for that one here: https://github.com/peteruhnak/git-migration/issues/19 The script I'm using is: migration:=GitMigration on:'Seaside/SeasideDynamicSVG'. migration ignoredFileNames: #('SeasideDynamicSVG-Core-hkl.86' 'SeasideDynamicSVG-Core-hkl.3' 'SeasideDynamicSVG-Tests-obi.7'). migration cacheAllVersions. migration populateCaches. migration allAuthors. migration authors:{ 'MaxBareis'-> #('Max Bareis' '<max(a)bareis.name>'). 'JohanBrichau' -> #('Johan Brichau' '<johanbrichau(a)me.com>'). 'hkl' -> #('Holger Kleinsorgen' '<h.kleinsorgen(a)gmail.com>'). 'go' -> #('Gerhard Obermann' '<obi068(a)gmail.com>'). 'obi' -> #('Gerhard Obermann' '<obi068(a)gmail.com>'). 'ThomasCleenewerck' -> #('ThomasCleenewerck' '<thomas(a)inceptive.be>'). 'TC' -> #('ThomasCleenewerck' '<thomas(a)inceptive.be>'). 'PaulDeBruicker' -> #('Paul DeBruicker' '<pdebruic(a)gmail.com>') }. "I change the SHA and the target file for each Pharo version" migration fastImportCodeToDirectory: 'gitmigration-repo' initialCommit:'a8d9d4c981f4e8aff4728b3ab84d296ebe77b4d5' to: '/Users/paul/Downloads/seaside-svg-pharo-7.txt' In pharo 7 to load git-migration I'm using Metacello new baseline: 'GitMigration'; repository: 'github://peteruhnak/git-migration/repository'; load. and in 6.1 & 6 I'm using Metacello new baseline: 'GitMigration'; repository: 'github://peteruhnak/git-migration:pharo6/repository'; load. Let me know if you have any ideas on what I should do to fix those errors in Pharo 6 & 6.1. If you have a copy of GitMigrationMemoryTreeGitRepository>>#writeGitFileTreeProperties: in one of your images I'd be happy to get a version of it and keep trying. It seems to me that I'll be better off porting everything to Pharo 7 then doing the migration to git. Sean P. DeNigris wrote > Paul DeBruicker wrote >> https://github.com/peteruhnak/git-migration seems to be broken on Pharo 6 > > Could you say more about your error(s)? I migrated many projects in Pharo > 6.1 with this tool > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 2, 2019

Re: [Pharo-users] Learn Pharo - Not Working

by Richard70NL

magicspeller wrote > You can learn Pharo by clicking on the following expression: > > ProfStef go. > > I clicked on ProfStef go and nothing happened. There are three URL links > on > the same page that work like they're supposed to, but no matter how many > times I try, clicking on ProfStef go appears to do nothing at all. For me it works, but what you can also try is: 1) Click the menu Tools -> Playground 2) Type: ProfStef go. 3) Right click what you just typed and click "Do It" BTW, I'm also new with Pharo (not with programming) and I really enjoy the book at http://books.pharo.org/pharo-by-example/. Cheers, Richard -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 2, 2019

Re: [Pharo-users] Learn Pharo - Not Working

by magicspeller

John Pfersich wrote > Did you use the 32-bit version or the 64-bit version? I just used Pharo > Launcher to start a 32-bit image. I clicked on âProfStef goâ and got a > separate window with the tutorial. I didnât try the 64-bit version; itâs > still beta software. Thanks again, John. I went to the download site and discovered that both 7.0 versions are labeled development versions. I downloaded and ran the 32-bit version. It works fine. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 2, 2019

Re: [Pharo-users] [vwnc] Falsehoods programmers believe about Smalltalk

by HernÃ¡n Morales Durand

Hi Cesar, El vie., 1 feb. 2019 a las 20:23, Cesar Rabak (<cesar.rabak(a)gmail.com>) escribiÃ³: > I'm having a good time reading to all those diatribes turned into > admonitions to 'non initiated' into the arcane art of Smalltalk. > > However, I see the need to inform you that as presented so far, the > phrases bring too much emotional content instead of intelligent down to > Earth updated to XXI century information! > > I know, and I mostly agree with you. The emotional part is totally on purpose, at least from my side, because these kind of articles are meant to shock readers, and motion curiosity. I won't see them as "admonitions" but a compilation of false or dubious perceptions about Smalltalk. As this is WIP we could also add specific examples supporting the claims, although I didn't seen it too much in other articles of this type. > For example, all the mentions to adverbs like *slow*, l*ess* and so on, > are subject to an analysis that only in a concrete context and specific > case can be correctly assayed. > > Again agreed. However I should say I need to see a backup yet to one of the greatest lies in software developement: "Python is easy" (which doesn't release smalltalkers from nothing, but is a nice reminder of rethoric power). One of my ideas behind asking in mailing-lists to well-known experts is to avoid ex silentio fallacy, but also is difficult to escape half-truth phrases. > Other class of objectionable arguments are about the implementations, they > bring an enthymeme that the specific feature or approach is not desirable > (e.g. fixed size bytecodes, etc.) without showing the reason for the need > to "defend" the position it seems to me that we are at a bar counter > discussing the tone of the color of the adversaries' sport teams uniforms... > > The fixed size bytecodes is a bad example, I should remove it. > Even the "General Myths" compiled in github would need to be better > addressed. > > For each of them, in the proper realm they are more than acceptable as a > reasonable proxy for the truth, notwithstanding disgust. > > For example: for what "real world" "real time" application can an example > be given that is not a convoluted "demonstration" of one vendor or an > application developed for academic research that is abandonware or > conversely was done in an earlier version of its Smalltalk environment? > > Bonus point if an example is used in production (meaning people is > collecting money due is use, and has been developed as recent need and not > a decision of not redo/recode a legacy application. > > Please note there are people which doesn't focus solely on industry goals, for example whatever you develop in academics today is to focus an extremely specific problem, and mostly impossible to measure in terms of money-making at least at scientific journal publication time. Factors of success in academic research software tools are completely different than industry, so yes it is very common to find "abandonware" there, but they weren't thought as a "adoptware" in the first place. Even if you do today a state-of-the-art genomic aligner, you can only measure real adoption after a few years (and citation factor is not a measure of adoption), and your users will be a few guys in laboratories and bioengineering niches. > My counter examples: > > IBM dropped its Smalltalk business. > > Interesting to see IBM mentioned as a referring player, here in Argentina is seen as one of the worst enterprises after the "IBM affair" [1] scandal. Tektronix used to employ Smalltalk in their intelligent instruments, no > longer: they follow another (industry standard) approach. > > We ourselves migrated to non smalltalk solutions for the code repos... > > Sad to read about your migration. I imagine wasn't something you did gladly. You know there are many articles and forums where Smalltalk is totally destroyed, without anyone to contend claims. And they aren't even "claims"... is just plain insulting without any experience to back up. Isn't any news anymore to read about weakness of Smalltalk implementations, lack of community support, quality, etc. That could be done with almost any developement tool, but strangely one cannot find so fierce criticism against bash, or R, when it's almost 2020 and debugging or testing with them is a complete nightmare. That doesn't mean we should support or reject any myths. I like to read both supports and constructive criticism. This is a complex subject and collecting experience samples/reports is something the community could use more. > *For every specific problem a specialized language would overperform all > others. However certain languages are inherently broad scope enough to keep > being mainstream.* > > Smalltalk currently can only be considered as niche > language/environment/whatever the purists would like to call it, but has > not caught the World. . . > True, but I'm not sure that catching the World is a reasonable goal. Making life easier for those now working with Smalltalk as a means of living could be more reasonable, at least for this age. It doesn't mean current-generation smalltalkers hasn't learnt nothing or cannot share any knowledge. Cheers, HernÃ¡n [1] https://medium.com/worm-capital/the-ibm-hall-of-shame-a-semi-complete-list-… > > My 0.019999 > > -- > Cesar Rabak > > > > > > On Fri, Feb 1, 2019 at 5:15 PM HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > >> Added to the list. >> Nice catch! >> >> Cheers, >> >> HernÃ¡n >> >> >> El vie., 1 feb. 2019 a las 2:33, stephen(a)heaveneverywhere.com (< >> stephen(a)heaveneverywhere.com>) escribiÃ³: >> >>> >>> How about: >>> >>> Smalltalk is less efficient than "low-level" languages. >>> >>> Smalltalk can't do "real time." >>> >>> Garbage collection is less efficient than manual memory management. >>> >>> Garbage collection is really slow if you use complex data structures. >>> >>> >>> stp >>> >>> >>> -- >>> >>> Stephen Travis Pope Santa Barbara, California, USA >>> >>> http://HeavenEverywhere.com http://FASTLabInc.com >>> https://vimeo.com/user19434036/videos *http://heaveneverywhere.com/Reflections >>> <http://heaveneverywhere.com/Reflections>* >>> >>> -- >>> >>> >>> >>> On Jan 28, 2019, at 5:22 AM, Reinout Heeck <vwnclist(a)soops.nl> wrote: >>> >>> >>> Smalltalk is a programming language. >>> >>> >>> >>> R >>> >>> - >>> >>> >>> >>> On 20-1-2019 23:31, HernÃ¡n Morales Durand wrote: >>> >>> Hi there, >>> >>> I just created a GitHub repo to collect myths around Smalltalk-based >>> technologies: Pharo, Squeak, VW, VAST, Smalltalk/X, GNU/ST, etc. in the >>> spirit of the Falsehoods lists [1-4]. >>> >>> This is just a draft now but please feel free to add falsehoods based on >>> your own experiences. Examples are greatly appreciated. >>> >>> https://github.com/hernanmd/falsehoods_smalltalk >>> >>> Cheers, >>> >>> HernÃ¡n >>> >>> [1] >>> https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-ab… >>> [2] >>> https://chiselapp.com/user/ttmrichter/repository/gng/doc/trunk/output/false… >>> [3] >>> https://github.com/googlei18n/libphonenumber/blob/master/FALSEHOODS.md >>> [4] >>> https://meta-package-manager.readthedocs.io/en/develop/falsehoods.html >>> >>> >>>

Feb. 2, 2019

Re: [Pharo-users] Why DirectoryIsNotEmpty on FileReference>>deleteAll ?

by Alistair Grant

Hi Albrecht, On Fri, 1 Feb 2019 at 19:50, Albrecht Baur via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > I get a DirectoryIsNotEmpty exception on > FileReference(AbstractFileReference)>>deleteAll. > > But deleteAll is supposed to delete children too. -> So why the exception ? This is a bug in the FilePlugin. When deleting directories it is leaving the deleted directory open. On Unix this is OK, the entry is removed from the parent directory and actually deleted when the file is closed. I assume that because CIFS is a windows protocol it doesn't handle it, and leaves the entry there until closed, causing the problems later on. The problem can be reduced to the following code: | root deleteMeFolder | root := '/path/to/cifs' asFileReference. deleteMeFolder := root / 'delme'. deleteMeFolder ensureCreateDirectory. deleteMeFolder delete. Then execute: $ sudo lsof | grep delme and you'll see the deleted entries. Issue: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/368 Cheers, Alistair

Feb. 2, 2019

Re: [Pharo-users] How to intercept instvar write - MetaLinks + anonymous subclass problem

by Steven Costiou

> Le 2019-02-02 16:26, Petr Fischer via Pharo-users a Ã©crit : > > Thanks for answer! I want to detect instvar writes only for objects (instances), that was previously fetched from external "datastore" (DB like), so I can persist changed objects only back to the datastore at the end of transaction. These objects can be any existing class (Pharo classes, some 3rd party libs classes, everything), so 1) injecting a class is overkill (affects all objects in the image) 2) impossible to rewrite #class method for every existing class. > > Injecting object-centric metalinks via anonymous subclass breaks up many things, when I want to treat injected object like any othres (IMHO). > > If you will be able to avoid this issue, that would be extra cool :-] > > Note: for now, best for my "instvar writes detection" would be probably hack Object>>#attemptToAssign:withIndex: or ProtoObject>>#modificationForbiddenFor:index:value: and make my "datastore fetched objects" read only (via Object>>#setIsReadOnlyObject. > > pf I will look into that yes, however object-centric metalinks are not really meant to affect all instnces, only specific ones. That is more the purpose of "standard" metalinks. Could standard metalinks not work? Since in any case you have to have your hand on those objects, so instead of putting an object-centric metalink you could ask for the class and install a normal metalink on write access there, which would affect all instances of that class. You would also have to keep some kind of record of which class you instrumented, so you do not install the link multiple times. Steven.

Feb. 2, 2019

Re: [Pharo-users] How to intercept instvar write - MetaLinks + anonymous subclass problem

by Petr Fischer

> > is possible to intercept (before writeÃº all instance variable writes on every existing objects? > > > > Ok, I learned more about MetaLinks and it's perfectly possible to intercept instance variable writes via. installing MetaLink into object instance (cool) - then I can intercept instvar write, but one problem immediately occurs: > > when installing MetaLink into object instance, an original object class is exchanged to anonymous subclass of the original class - and because typical #= method is implemented like: > > > > = > > self == anObject > > ifTrue: [ ^ true ]. > > self class = anObject class > > ifFalse: [ ^ false ]. > > ... > > > > then most of #= comparisons in application logic is broken due to "self class = anObject class" part. > > > > Is there any way to solve this problem? > > Hi, > > the anonymous class thing only happen when you install an object-centric > metalink, i.e. on only one specific object. I also wanted to hide the > anonymous class, or maybe to only make it visible for environment tools. > I need to talk about that with Marcus. > > Why not installing your metalink on the classes of your objects, so that > all instances are affected but in that case there is no anonymous class > migration? > > If that is not possible, in your case maybe a (temporary) hack would be, > in your case, to add a test in the #class method in Object (or wherever > it is defined): > > class > > |myClass| > > myClass := self class. > > ^myClass isAnonymous ifTrue:[myClass superclass] ifFalse:[myClass] > > But i did not test that and i have no idea of the overall impact. > > Steven. Thanks for answer! I want to detect instvar writes only for objects (instances), that was previously fetched from external "datastore" (DB like), so I can persist changed objects only back to the datastore at the end of transaction. These objects can be any existing class (Pharo classes, some 3rd party libs classes, everything), so 1) injecting a class is overkill (affects all objects in the image) 2) impossible to rewrite #class method for every existing class. Injecting object-centric metalinks via anonymous subclass breaks up many things, when I want to treat injected object like any othres (IMHO). If you will be able to avoid this issue, that would be extra cool :-] Note: for now, best for my "instvar writes detection" would be probably hack Object>>#attemptToAssign:withIndex: or ProtoObject>>#modificationForbiddenFor:index:value: and make my "datastore fetched objects" read only (via Object>>#setIsReadOnlyObject:). pf

Feb. 2, 2019

Re: [Pharo-users] How to intercept every instance variable write on all objects

by Peter Uhnak

Hi, 3) Metalinks - it's based on intercepting method calls, right? But I need to intercept direct instance variable write, so probably not possible no, you can attach metalink to any AST node, including an Assignment Node. Some years ago I've made a small utility for this that also auto-reinstalled when the method has changed. Should work with P6, not sure about the current P7 https://github.com/peteruhnak/metalinks-toolkit . But of course you can attach the MetaLink directly. P On Fri, Feb 1, 2019 at 12:43 AM Petr Fischer via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Hello, > > is possible to intercept (before writeÃº all instance variable writes on > every existing objects? > > I found a discussion here: > > http://forum.world.st/Is-it-possible-to-follow-an-object-through-a-computat… > > Known solutions: > > 1) jugglery with object read only state + ModificationForbidden - not > ideal, it's probably slow via exceptions and every nested on:do: stop > change detection > > 2) it's possible to do it via slots - but it does not work on any existing > object (only on my specially prepared objects with slots) > > 3) Metalinks - it's based on intercepting method calls, right? But I need > to intercept direct instance variable write, so probably not possible > > Is there any way? Thanks! pf > > > >

Feb. 2, 2019

Re: [Pharo-users] PharoV50.sources in VM?

by Alistair Grant

On Sat, 2 Feb 2019 at 09:32, Hilaire <hilaire(a)drgeo.eu> wrote: > > Thanks for the update. > > By the way, is there any reason to not remove the symbols in the Windows > and Linux VM libraries? It saves several MB. At least for DrGeo > distribution, there is no use. I'm not sure what the impact of this would be, so would prefer others to comment. > Hilaire > > Le 02/02/2019 Ã 09:01, Alistair Grant a Ã©crit : > > I can't see any reason for keeping this. The sources file is now > > generated for each image, so it doesn't make sense to distribute it > > with the VM. > > > > I'll remove this in a few days if there aren't any other objections. It looks like this is a linux only issue (I downloaded Win and Mac VMs and the sources aren't present). Issue: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/365 PR: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/366 Cheers, Alistair

Feb. 2, 2019