January 2016 - Pharo-users - lists.pharo.org

[ANN] First release of FFICHeaderExtractor

by Mariano Martinez Peck

Dear all, I am happy to announce the first release of FFICHeaderExtractor project. You can find the project and the documentation here: https://github.com/marianopeck/FFICHeaderExtractor Any feedback is more than welcome. Best, -- Mariano http://marianopeck.wordpress.com

Jan. 27, 2016

Re: [Pharo-users] Pharo 5 new vm crash on window resize

by Skip Lentz

Hi, Iâm reviving this thread, since I had a similar crash also on latest Spur VM (http://get.pharo.org/vmLatest50) Happens when resizing to fullscreen or to maximum (with alt+click on the expand button on OSX) while loading a project with Metacello. Possibly it happens any time when you resize while a Job is running? Dump: https://gist.github.com/Balletie/bc20bed37db42991de98 Sorry for the spam if this problem is already in the process of being fixed. Skip > On Jan 17, 2016, at 3:48 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > Le 16/01/2016 16:50, Johan Fabry a Ã©crit : >> Hi all, >> >> this just happened to me: I opened a new image (todayâs build), resized it and the VM segfaulted. I am on MacOS. crash.dmp is in attachment. I have been unable to reproduce, sadly. Is this a known issue or should I add a new bug report ? >> >> >> ---> Save our in-boxes! http://emailcharter.org <--- >> >> Johan Fabry - http://pleiad.cl/~jfabry >> PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile >> > > Hi, > > I had this issue not long ago by resizing during the setting loading. > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France >

Jan. 27, 2016

Re: [Pharo-users] Pharo + git workflow

by Thierry Goubier

Hi Norbert, the development version on Pharo4 has the credentials working now. It switches to https instead of ssh if you add a username and a password, since a ssh url can't carry a password and, in the case of github, the ssh user is allways git. Thierry Le 26/01/2016 13:32, Norbert Hartl a Ã©crit : > >> Am 26.01.2016 um 13:03 schrieb Norbert Hartl <norbert(a)hartl.name >> <mailto:norbert@hartl.name>>: >> >>> >>> Am 25.01.2016 um 23:32 schrieb Thierry Goubier >>> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>>: >>> >>> Le 25/01/2016 23:13, Norbert Hartl a Ã©crit : >>>> >>>>> Am 25.01.2016 um 23:02 schrieb Norbert Hartl <norbert(a)hartl.name >>>>> <mailto:norbert@hartl.name>>: >>>>> >>>>> Hi, >>>>> >>>>>> Am 25.01.2016 um 22:55 schrieb Thierry Goubier >>>>>> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>>: >>>>>> >>>>>> Hi Norbert, >>>>>> >>>>>> Just tell me if you need any additional parameter to the git clone >>>>>> for the credentials, because I'm not sure I have written the code >>>>>> which will handle them. >>>>>> >>>>> I'll check that. The easiest approach is to use the authority part >>>>> of the url like >>>>> >>>>> https://user:pass@bitbucket.org/â¦. >>> >>> I'm nearly sure my code doesn't check for them and silently drop them :( >>> >>>>> I try that tomorrow. >>>>> >>>> But then I don't think that sub-directories work per http. >>> >>> They do over https. But remember the syntax is, to take your url, >>> >>> gitfiletree://user:pass@bitbucket.org/...?protocol=https >> >> Does not work for me. It complains about unknown url scheme. But using >> the read-only version of gitfiletree would still mean I have to >> install gitfiletree, no? I have no glue hot the url with bitbucket:// >> could work. >>> >>> I wonder if I can write code that considers that if you have a >>> username and a password, then it should use https and not ssh. >> >> I see no reason why. You can use ssh with username and password as well. >> > Ok, I got it through the unknown url scheme but indeed the credentials > are stripped off. > > Norbert >

Jan. 27, 2016

Re: [Pharo-users] Regex usage question

by Dimitris Chloupis

Nope you should not apologize , you are not expected to read class comments before asking questions here. You will find a dedicate chapter on regex on Deep Into Pharo which you can download as free PDFs from the Pharo website. Pharo regex is very similar to other languages , AFAIK it's nothing special. I used it for language parsing from Pharo to Python syntax. But if you really want to do some complex parsing I highly recommend powerful parser like SmaCC and PettitParser , the good news is that they use syntax very similar to regex but far more readable, flexible and powerful. I used SmaCC which comes with good documentation and ton of examples , I think PettitParser is similar story. On Tue, 26 Jan 2016 at 19:53, Cameron Sanders via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Ah! I found the RxParser class methods for syntax and usage. I missed > these previously -- my apologies. > > On Tue, Jan 26, 2016 at 12:40 PM, Cameron Sanders <camsanders(a)aol.com> > wrote: > >> Hi All. Nice work on Pharo! >> >> We are starting to use the Regex pattern matching by allowing users to >> write "rules" using patterns. For example, our data lookup processing can >> include a 'Per' rule that takes a key such as 'xPerY' and returns the value >> of (data at: #x) / (data at: #y). Until recently, all binary-operators such >> as Per were performed with a simple string matches. But in order to >> generalize, we are moving regex patterns. >> >> Can someone tell me where the language-spec is for Regex-Core that is >> included in Pharo? Is this in the style of sed, awk, or ... ? If possible, >> how do I indicated that I want several sub-string replacement sections? >> >> Thanks in advance. >> -Cam >> > >

Jan. 26, 2016

Re: [Pharo-users] Pharo + git workflow

by Dimitris Chloupis

I love live coding , dynamic language, beautiful syntax and close integration with IDE. But yeah Monticello , I don't get it. I love Pharo and always respect the hard work of others but that does not mean I love every part of it. Same story is Blender , Python and all other tools I use. That ok I don't worry if some parts I don't like. It's what make with the tools you have that matters most. On Tue, 26 Jan 2016 at 19:46, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Sometimes I really don't understand what you see in Pharo ... > > > On 26 Jan 2016, at 17:53, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > "If git compares two versions, it does not understand what is in it." > > > > why it should ? its a version control system, not a refactoring tool. > > > > " > > When Monticello compares versions, it knows about classes, methods, > inheritance, > > it can explain diffs in the same structured (browsable) form that you > wrote them." > > > > is that Monticello or is that refactoring classes and methods of pharo ? > Because the way I see it is like this if you have a refactoring language, a > language that can refactor its own code , that language should be able to > take two diffirent pieces of code and not only show you a diff but also > show you how your inheritance is affected, your classes even your live > state. > > > > The big question here, from my side is why a version control system > should do that ? Refactoring and version controlling for me at least is two > very different tasks. I dont also see how a version control system that is > self aware refactoring wise when already have refactoring tools in my IDE, > is giving me any advantage me as a user. Most IDEs come with them anyway. > > > > Its not as if you will use a python IDE, or whatever language you use > and the IDE will go "sorry dude I cannot tell you what git did there > because it has no refactoring and I am too stupid to use my own refactoring > tools". That IDE would belong to the bin. This is why we use specialized > Git gui tools, they are not there just to make our screens pretty. > > > > "Putting Smalltalk in plain text files can be done, has been done, and > was not successful, because you lose something essential by leaving the > environment." > > > > What you lose is the live state which monticello does not store anyway, > how could it ? it only stores text files, its actually far more > anti-Smalltalk than git is. Because with git you can version control your > pharo images or your fuel files than contain the live state or you could > export the live state and live code to a binary file. Now try that with > monticello. The irony is very large, Git is far more Smalltalk friendly, > than Monticello is. > > > > "The island argument is also a bit too easy: any platform can be seen as > an island that needs to integrate with others, there are degrees of > openness. Your Blender or Python are islands too, just like SAP, Microsoft > and Oracle. Some connections/interfaces are easy, some are hard(er). It all > depends on your position." > > > > I completely agree in the end every API ever programm is to a degree an > island. No code ever shakes in terror saying "oh my god I need to make my > code 100% compatible with whatever is out there" . Its not possible. But > the culture of those other languages is "lets keep things close" , "lets > make coder's life" easier , "lets keep compatibility and standard/common > practices" . > > > > Smalltalk does not do that because it loves experimentation, the whole > smalltalk enviroment is experimentation heaven playground. Thats great > because without it we dont have smalltalk but its also bad. > > > > "When have you last looked at the source code of git ?" > > > > Never ? Why should I, I dont even take a look at monticello source code. > I tried to improve auto completion and my head kept spinning around and > around, 10s of hours still could not figure out the code. I am not smart or > knowledgable to judge Monticello on a source code basis. Maybe source code > wise, core wise, Monticello is 1000 times better than Git, but my complains > with Monticello is on the user level. As a smalltalker I just dont see the > point of prefering Monticello over Git , or screw Git, you want mercurial ? > thats fine too. > > > > I just dont see it whats the big deal with Monticello. > > > > "And be honest, do you find git always easy to use ?" > > > > I have been honest from the very start when I started pushing for git > and Github. I have been crystal clear. My usage of git is super simple. > > > > I dont work in teams, I work alone, I dont even use branches, I do git > pull, git add, git commit and git push. I have reverted commits a couple of > times, I have reset to head sometimes because of some nasty merges and that > was it. I am almost never have merge conflicts. > > > > You want me to compare my experience with monticello and StHub VS git > and Github using Pharo ? Nope you dont. > > > > Do I find git always easy to use ? You know what , I am a python coder > and I definetly appreciate ease of use and simplicity but lets be frank > here Git was made by the same guy that made the freaking Linux kernel. He > made Git not to be easy but able to manage an enormous amount of code the > easy way the fastest possible way and he accomplished that goal. > > > > So do I find git easy to use ? Nope > > > > Do I care ? Nope, because I rather use something that is difficult to > use but powerful and with good performance than something that is very easy > to use , limited and slow. Hell , I dont even find Pharo easy to use , its > power and flexibility that made me love it. > > > > > > On Tue, Jan 26, 2016 at 6:23 PM Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > > > On 26 Jan 2016, at 16:49, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > > > Obviously it will better fit Pharo since its made to work with > smalltalk code, but that does not make it any less terrible. Just because > you have one implementation of something that does not mean its good. Its > just means its there and it works. > > > > > > I dont know the internal, they are not documented anyway, there are > some class comments here and there but thats pretty much it. I dont even > remember when was the last time monticello got an updated, I mean a serious > update not just a couple of bug fixes the 2 years I have been around. > > > > > > Secondly GUI is just plain awful, Smalltalk maybe be the first or one > of the first to implement guis, but those implementations never ended up to > something that would be approachable and easy to use on a day to day basis, > some tools suffer more from this some less, Monticello is up there with the > worse design. > > > > > > Thirdly the inability of the system to version control images , audio > files and other assets it defeats the central purpose of smalltalk of > everything being objects with a loud "Nope !" from Monticello "Only source > code is". > > > > > > So its awesome that Smalltalk , and Squeak got its own version control > system, that is easy to use and Pharo inherited it. Congratulations to > people behind it. But the GUI needs to go, its a bad advertisement to > Pharo, and we need something that is not stuck to dark ages as you > correctly pointed but for the opposite reason. Because any way you try to > turn Monticello you wont find a label written "modern" on it. The label you > may find on it is more like "abandonware". > > > > > > Also there like a ton of OOP languages out there using git with no > major problems, the problem with smalltalk is that smalltalk is an island. > > > > > > And the problem with islands is when you end having fun with them you > feel stuck since they dont provide an easy access to the outside world. > > > > > > "Git just manages blobs, text files at best. Dead text" > > > > > > Last time I checked Monticello used a format called mcz which is > nothing more than a zip file containing st files, which are as you call it > "dead text" files. Also I would like to remind you that git is used by the > CUIS smalltalk to version control their images, I thought images are live > code. > > > > > > Personally I dont see the diffirence between live and dead text. Its > just text to me. The VM is the one that makes it live anyway. > > > > Yes and no. > > > > If git compares two versions, it does not understand what is in it. > > > > When Monticello compares versions, it knows about classes, methods, > inheritance, > > it can explain diffs in the same structured (browsable) form that you > wrote them. > > > > Putting Smalltalk in plain text files can be done, has been done, and > was not successful, because you lose something essential by leaving the > environment. > > > > The island argument is also a bit too easy: any platform can be seen as > an island that needs to integrate with others, there are degrees of > openness. Your Blender or Python are islands too, just like SAP, Microsoft > and Oracle. Some connections/interfaces are easy, some are hard(er). It all > depends on your position. > > > > When have you last looked at the source code of git ? > > > > And be honest, do you find git always easy to use ? > > > > > On Tue, Jan 26, 2016 at 5:09 PM Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > > > > > On 26 Jan 2016, at 15:59, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > > > > > To be fair my experience with pharo and git have been not always > smooth either. I have the VM crashing again and again completely randomly > when it was trying to pull SmaCC as dependency for my project Ephestos, had > to drop SmaCC and moving my python type parsing at python side. > > > > > > > > But I find it ironic someone using Monticello, trying to equate git > with dark ages, you cant get more dark ages than monticello, frankly. No > offense to people who made it , its great that is in there but its full of > problems and bad designs and cant even begin to be compared with Github and > GIT GUI clients. Monticello is according to my personal opinion by far the > worst tool of Pharo. > > > > > > No it is not. It is a version management system that understands our > object and code model, a system that we control. Git just manages blobs, > text files at best. Dead text. > > > > > > (This does not mean it is perfect, nor that it cannot improve, nor > that we should not improve our git integration.) > > > > > > > On Tue, Jan 26, 2016 at 4:51 PM Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > > > > 2016-01-26 15:11 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > > > > NorbertHartl wrote > > > > > - I need to use BaselineOf instead of ConfigurationOf. Thus you > cannot use > > > > > Versionner anymore > > > > > > > > Unfortunately. This is the biggest drag for me after switching all my > > > > personal projects to git (GitHub for public and BitBucket for > private). I > > > > had gotten spoiled by Versionner and hand-editing MetaC artifacts > feels like > > > > going back to the dark ages :/ > > > > > > > > Well, I guess copying the baselines generated by Versionner into a > BaselineOf is probably a way to do it. > > > > > > > > Thierry > > > > > > > > > > > > > > > > > > > > ----- > > > > Cheers, > > > > Sean > > > > -- > > > > View this message in context: > http://forum.world.st/Pharo-git-workflow-tp4874067p4874221.html > > > > Sent from the Pharo Smalltalk Users mailing list archive at > Nabble.com. > > > > > > > > > > > > > > > > >

Jan. 26, 2016

Re: Regex usage question

by Cameron Sanders

Ah! I found the RxParser class methods for syntax and usage. I missed these previously -- my apologies. On Tue, Jan 26, 2016 at 12:40 PM, Cameron Sanders <camsanders(a)aol.com> wrote: > Hi All. Nice work on Pharo! > > We are starting to use the Regex pattern matching by allowing users to > write "rules" using patterns. For example, our data lookup processing can > include a 'Per' rule that takes a key such as 'xPerY' and returns the value > of (data at: #x) / (data at: #y). Until recently, all binary-operators such > as Per were performed with a simple string matches. But in order to > generalize, we are moving regex patterns. > > Can someone tell me where the language-spec is for Regex-Core that is > included in Pharo? Is this in the style of sed, awk, or ... ? If possible, > how do I indicated that I want several sub-string replacement sections? > > Thanks in advance. > -Cam >

Jan. 26, 2016

Re: [Pharo-users] Pharo + git workflow

by Sven Van Caekenberghe

Sometimes I really don't understand what you see in Pharo ... > On 26 Jan 2016, at 17:53, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > "If git compares two versions, it does not understand what is in it." > > why it should ? its a version control system, not a refactoring tool. > > " > When Monticello compares versions, it knows about classes, methods, inheritance, > it can explain diffs in the same structured (browsable) form that you wrote them." > > is that Monticello or is that refactoring classes and methods of pharo ? Because the way I see it is like this if you have a refactoring language, a language that can refactor its own code , that language should be able to take two diffirent pieces of code and not only show you a diff but also show you how your inheritance is affected, your classes even your live state. > > The big question here, from my side is why a version control system should do that ? Refactoring and version controlling for me at least is two very different tasks. I dont also see how a version control system that is self aware refactoring wise when already have refactoring tools in my IDE, is giving me any advantage me as a user. Most IDEs come with them anyway. > > Its not as if you will use a python IDE, or whatever language you use and the IDE will go "sorry dude I cannot tell you what git did there because it has no refactoring and I am too stupid to use my own refactoring tools". That IDE would belong to the bin. This is why we use specialized Git gui tools, they are not there just to make our screens pretty. > > "Putting Smalltalk in plain text files can be done, has been done, and was not successful, because you lose something essential by leaving the environment." > > What you lose is the live state which monticello does not store anyway, how could it ? it only stores text files, its actually far more anti-Smalltalk than git is. Because with git you can version control your pharo images or your fuel files than contain the live state or you could export the live state and live code to a binary file. Now try that with monticello. The irony is very large, Git is far more Smalltalk friendly, than Monticello is. > > "The island argument is also a bit too easy: any platform can be seen as an island that needs to integrate with others, there are degrees of openness. Your Blender or Python are islands too, just like SAP, Microsoft and Oracle. Some connections/interfaces are easy, some are hard(er). It all depends on your position." > > I completely agree in the end every API ever programm is to a degree an island. No code ever shakes in terror saying "oh my god I need to make my code 100% compatible with whatever is out there" . Its not possible. But the culture of those other languages is "lets keep things close" , "lets make coder's life" easier , "lets keep compatibility and standard/common practices" . > > Smalltalk does not do that because it loves experimentation, the whole smalltalk enviroment is experimentation heaven playground. Thats great because without it we dont have smalltalk but its also bad. > > "When have you last looked at the source code of git ?" > > Never ? Why should I, I dont even take a look at monticello source code. I tried to improve auto completion and my head kept spinning around and around, 10s of hours still could not figure out the code. I am not smart or knowledgable to judge Monticello on a source code basis. Maybe source code wise, core wise, Monticello is 1000 times better than Git, but my complains with Monticello is on the user level. As a smalltalker I just dont see the point of prefering Monticello over Git , or screw Git, you want mercurial ? thats fine too. > > I just dont see it whats the big deal with Monticello. > > "And be honest, do you find git always easy to use ?" > > I have been honest from the very start when I started pushing for git and Github. I have been crystal clear. My usage of git is super simple. > > I dont work in teams, I work alone, I dont even use branches, I do git pull, git add, git commit and git push. I have reverted commits a couple of times, I have reset to head sometimes because of some nasty merges and that was it. I am almost never have merge conflicts. > > You want me to compare my experience with monticello and StHub VS git and Github using Pharo ? Nope you dont. > > Do I find git always easy to use ? You know what , I am a python coder and I definetly appreciate ease of use and simplicity but lets be frank here Git was made by the same guy that made the freaking Linux kernel. He made Git not to be easy but able to manage an enormous amount of code the easy way the fastest possible way and he accomplished that goal. > > So do I find git easy to use ? Nope > > Do I care ? Nope, because I rather use something that is difficult to use but powerful and with good performance than something that is very easy to use , limited and slow. Hell , I dont even find Pharo easy to use , its power and flexibility that made me love it. > > > On Tue, Jan 26, 2016 at 6:23 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 26 Jan 2016, at 16:49, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > > > Obviously it will better fit Pharo since its made to work with smalltalk code, but that does not make it any less terrible. Just because you have one implementation of something that does not mean its good. Its just means its there and it works. > > > > I dont know the internal, they are not documented anyway, there are some class comments here and there but thats pretty much it. I dont even remember when was the last time monticello got an updated, I mean a serious update not just a couple of bug fixes the 2 years I have been around. > > > > Secondly GUI is just plain awful, Smalltalk maybe be the first or one of the first to implement guis, but those implementations never ended up to something that would be approachable and easy to use on a day to day basis, some tools suffer more from this some less, Monticello is up there with the worse design. > > > > Thirdly the inability of the system to version control images , audio files and other assets it defeats the central purpose of smalltalk of everything being objects with a loud "Nope !" from Monticello "Only source code is". > > > > So its awesome that Smalltalk , and Squeak got its own version control system, that is easy to use and Pharo inherited it. Congratulations to people behind it. But the GUI needs to go, its a bad advertisement to Pharo, and we need something that is not stuck to dark ages as you correctly pointed but for the opposite reason. Because any way you try to turn Monticello you wont find a label written "modern" on it. The label you may find on it is more like "abandonware". > > > > Also there like a ton of OOP languages out there using git with no major problems, the problem with smalltalk is that smalltalk is an island. > > > > And the problem with islands is when you end having fun with them you feel stuck since they dont provide an easy access to the outside world. > > > > "Git just manages blobs, text files at best. Dead text" > > > > Last time I checked Monticello used a format called mcz which is nothing more than a zip file containing st files, which are as you call it "dead text" files. Also I would like to remind you that git is used by the CUIS smalltalk to version control their images, I thought images are live code. > > > > Personally I dont see the diffirence between live and dead text. Its just text to me. The VM is the one that makes it live anyway. > > Yes and no. > > If git compares two versions, it does not understand what is in it. > > When Monticello compares versions, it knows about classes, methods, inheritance, > it can explain diffs in the same structured (browsable) form that you wrote them. > > Putting Smalltalk in plain text files can be done, has been done, and was not successful, because you lose something essential by leaving the environment. > > The island argument is also a bit too easy: any platform can be seen as an island that needs to integrate with others, there are degrees of openness. Your Blender or Python are islands too, just like SAP, Microsoft and Oracle. Some connections/interfaces are easy, some are hard(er). It all depends on your position. > > When have you last looked at the source code of git ? > > And be honest, do you find git always easy to use ? > > > On Tue, Jan 26, 2016 at 5:09 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > On 26 Jan 2016, at 15:59, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > > > > > To be fair my experience with pharo and git have been not always smooth either. I have the VM crashing again and again completely randomly when it was trying to pull SmaCC as dependency for my project Ephestos, had to drop SmaCC and moving my python type parsing at python side. > > > > > > But I find it ironic someone using Monticello, trying to equate git with dark ages, you cant get more dark ages than monticello, frankly. No offense to people who made it , its great that is in there but its full of problems and bad designs and cant even begin to be compared with Github and GIT GUI clients. Monticello is according to my personal opinion by far the worst tool of Pharo. > > > > No it is not. It is a version management system that understands our object and code model, a system that we control. Git just manages blobs, text files at best. Dead text. > > > > (This does not mean it is perfect, nor that it cannot improve, nor that we should not improve our git integration.) > > > > > On Tue, Jan 26, 2016 at 4:51 PM Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2016-01-26 15:11 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > > > NorbertHartl wrote > > > > - I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use > > > > Versionner anymore > > > > > > Unfortunately. This is the biggest drag for me after switching all my > > > personal projects to git (GitHub for public and BitBucket for private). I > > > had gotten spoiled by Versionner and hand-editing MetaC artifacts feels like > > > going back to the dark ages :/ > > > > > > Well, I guess copying the baselines generated by Versionner into a BaselineOf is probably a way to do it. > > > > > > Thierry > > > > > > > > > > > > > > > ----- > > > Cheers, > > > Sean > > > -- > > > View this message in context: http://forum.world.st/Pharo-git-workflow-tp4874067p4874221.html > > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > > > > >

Jan. 26, 2016

Regex usage question

by Cameron Sanders

Hi All. Nice work on Pharo! We are starting to use the Regex pattern matching by allowing users to write "rules" using patterns. For example, our data lookup processing can include a 'Per' rule that takes a key such as 'xPerY' and returns the value of (data at: #x) / (data at: #y). Until recently, all binary-operators such as Per were performed with a simple string matches. But in order to generalize, we are moving regex patterns. Can someone tell me where the language-spec is for Regex-Core that is included in Pharo? Is this in the style of sed, awk, or ... ? If possible, how do I indicated that I want several sub-string replacement sections? Thanks in advance. -Cam

Jan. 26, 2016

Pharo and OpenMP

by Dimitris Chloupis

First my apology for the very long post but I think this will interest a lot of people. I have seen that someone out there .... HELOOOOOOO.... has tried Pharo with OpenMP https://pharoweekly.wordpress.com/2015/07/17/pharo-and-openmp/ For those that dont know what the hell OpenMP is, it nothing more than a collection of C pragmas, not very diffirent to our pharo pragmas , that tell to a compiler how to make code parallel. By parallel I don't mean pharo threads which are not really code that executes at the same time but true hardware threads and taking advantage of multiple cores etc. A pharo holy grail. Parallel coding is a bitch, there a lot of logical problems to face when you have pieces of code executing at the same time and you have to be aware of how the hardware is doing it because if you dont it so easy to get code as slow as running it on a single thread. I have been watching youtube tutorials by one of the guys that made OpenMP and I have to say I am very impressed. And it got me wondering "why the hell not pharo". The nice thing about OpenMP is that it does not matter that pharo VM can do only 1 thread which is the main thread, you can do multiple threads at C side using OpenMP and then collapse them to one thread and send the result back to pharo. Also note OpenMP is engineered by Intel so its a very serious library and comes included with most modern compilers and that includes GCC. Visual Studio and Clang / LLVM On the other hand lately I am also researching shared memory, actually its shared memory that lead me to OpenMP. My idea is basically extending the live coding enviroment of pharo beyond pharo. Its sound a bit crazy but the way I see it from my very small knowledge of C and shared memory is that right now, pharo live coding evniroment is isolated from outside world. You can do live coding while inside pharo but the moment you go outside , say you call a C library , live coding goes out of the window. This why we need to have session management to manage resource of calling C libraries to make sure when we reload the image , the image does not freak out that the live state of the C libraries is gone. This is also why many people push things to the image side. And of course its much more fun to code in Pharo than C. Now bare with me because things are now getting really interesting.... what if we could have an image flle for C code ? The things is that I am interested into shared memory because I want a very fast IPC, shared memory is the faster. I want to communicate Pharo with Blender, that I have accomplished via sockets, I can call python code and python libraries from pharo. But sockets are expensive in large loops, they work great for simple communication and much faster than pipes when used locally but try a large loop and socket will lag. Shared memory on the other hand is super fast, it basically it gives a part of memory that is shared among process that means also different applications. Now how a C image file fits into all this you may ask. Its simple. The most popular way of shared memory is called "memory mapped file", what it does is that it takes a file and loads it to memory as it is... sound familiar ? ;) what however is also doing is that it allows you share that part of the memory with any other application/ process as long as it also tries to load the file mapped to memory the same way. So what that means that we can have a place in memory that is shared between C code, including C dlls, and Pharo code. That file can act as an image file because we take that shared memory at any time that has been modified either by pharo, C or whatever else has access to shared memmory and store it back to that file. This is functionality that memory mapped files provide called msync. We talk here about a C image that work at least on surface very similarly to Pharo image. Now where OpenMP fits in all this ? Since OpenMP is about code that eats processors like peanuts , yes we could call it from a DLL, but with my approach even if that code crashes we will be able to restore it back to its live state because of that image format. All we do is reopen the memory mapped file and restore from it the shared memory. So we end up with true parallel live C/Pharo code with live state that and of course live code that is shared between Pharo and pretty much anything that uses C or python or why not other languages. So far I know how to do all of the above, well at least I am learning it now. Now the real challenge, which I have no clue about, is to make a Pharo parser to C using OpenMP. My thinking is as following. Why code in C and OpenMP when you could take something like Slang, which is basically pharo code that compiles to C, use pharo code with some pharo pragmas corresponding to OpenMP pragmas that will allow you to compile Slang OpenMP to C OpenMP and then compile it to an executable or dll that uses the shared memory memory mapped file solution. Crazy ? realistic ? far fetched ? maybe ? good in theory back in practice? Open to your thoughts.

Jan. 26, 2016

Re: [Pharo-users] Pharo + git workflow

by Dimitris Chloupis

"If git compares two versions, it does not understand what is in it." why it should ? its a version control system, not a refactoring tool. " When Monticello compares versions, it knows about classes, methods, inheritance, it can explain diffs in the same structured (browsable) form that you wrote them." is that Monticello or is that refactoring classes and methods of pharo ? Because the way I see it is like this if you have a refactoring language, a language that can refactor its own code , that language should be able to take two diffirent pieces of code and not only show you a diff but also show you how your inheritance is affected, your classes even your live state. The big question here, from my side is why a version control system should do that ? Refactoring and version controlling for me at least is two very different tasks. I dont also see how a version control system that is self aware refactoring wise when already have refactoring tools in my IDE, is giving me any advantage me as a user. Most IDEs come with them anyway. Its not as if you will use a python IDE, or whatever language you use and the IDE will go "sorry dude I cannot tell you what git did there because it has no refactoring and I am too stupid to use my own refactoring tools". That IDE would belong to the bin. This is why we use specialized Git gui tools, they are not there just to make our screens pretty. "Putting Smalltalk in plain text files can be done, has been done, and was not successful, because you lose something essential by leaving the environment." What you lose is the live state which monticello does not store anyway, how could it ? it only stores text files, its actually far more anti-Smalltalk than git is. Because with git you can version control your pharo images or your fuel files than contain the live state or you could export the live state and live code to a binary file. Now try that with monticello. The irony is very large, Git is far more Smalltalk friendly, than Monticello is. "The island argument is also a bit too easy: any platform can be seen as an island that needs to integrate with others, there are degrees of openness. Your Blender or Python are islands too, just like SAP, Microsoft and Oracle. Some connections/interfaces are easy, some are hard(er). It all depends on your position." I completely agree in the end every API ever programm is to a degree an island. No code ever shakes in terror saying "oh my god I need to make my code 100% compatible with whatever is out there" . Its not possible. But the culture of those other languages is "lets keep things close" , "lets make coder's life" easier , "lets keep compatibility and standard/common practices" . Smalltalk does not do that because it loves experimentation, the whole smalltalk enviroment is experimentation heaven playground. Thats great because without it we dont have smalltalk but its also bad. "When have you last looked at the source code of git ?" Never ? Why should I, I dont even take a look at monticello source code. I tried to improve auto completion and my head kept spinning around and around, 10s of hours still could not figure out the code. I am not smart or knowledgable to judge Monticello on a source code basis. Maybe source code wise, core wise, Monticello is 1000 times better than Git, but my complains with Monticello is on the user level. As a smalltalker I just dont see the point of prefering Monticello over Git , or screw Git, you want mercurial ? thats fine too. I just dont see it whats the big deal with Monticello. "And be honest, do you find git always easy to use ?" I have been honest from the very start when I started pushing for git and Github. I have been crystal clear. My usage of git is super simple. I dont work in teams, I work alone, I dont even use branches, I do git pull, git add, git commit and git push. I have reverted commits a couple of times, I have reset to head sometimes because of some nasty merges and that was it. I am almost never have merge conflicts. You want me to compare my experience with monticello and StHub VS git and Github using Pharo ? Nope you dont. Do I find git always easy to use ? You know what , I am a python coder and I definetly appreciate ease of use and simplicity but lets be frank here Git was made by the same guy that made the freaking Linux kernel. He made Git not to be easy but able to manage an enormous amount of code the easy way the fastest possible way and he accomplished that goal. So do I find git easy to use ? Nope Do I care ? Nope, because I rather use something that is difficult to use but powerful and with good performance than something that is very easy to use , limited and slow. Hell , I dont even find Pharo easy to use , its power and flexibility that made me love it. On Tue, Jan 26, 2016 at 6:23 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 26 Jan 2016, at 16:49, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > Obviously it will better fit Pharo since its made to work with smalltalk > code, but that does not make it any less terrible. Just because you have > one implementation of something that does not mean its good. Its just means > its there and it works. > > > > I dont know the internal, they are not documented anyway, there are some > class comments here and there but thats pretty much it. I dont even > remember when was the last time monticello got an updated, I mean a serious > update not just a couple of bug fixes the 2 years I have been around. > > > > Secondly GUI is just plain awful, Smalltalk maybe be the first or one of > the first to implement guis, but those implementations never ended up to > something that would be approachable and easy to use on a day to day basis, > some tools suffer more from this some less, Monticello is up there with the > worse design. > > > > Thirdly the inability of the system to version control images , audio > files and other assets it defeats the central purpose of smalltalk of > everything being objects with a loud "Nope !" from Monticello "Only source > code is". > > > > So its awesome that Smalltalk , and Squeak got its own version control > system, that is easy to use and Pharo inherited it. Congratulations to > people behind it. But the GUI needs to go, its a bad advertisement to > Pharo, and we need something that is not stuck to dark ages as you > correctly pointed but for the opposite reason. Because any way you try to > turn Monticello you wont find a label written "modern" on it. The label you > may find on it is more like "abandonware". > > > > Also there like a ton of OOP languages out there using git with no major > problems, the problem with smalltalk is that smalltalk is an island. > > > > And the problem with islands is when you end having fun with them you > feel stuck since they dont provide an easy access to the outside world. > > > > "Git just manages blobs, text files at best. Dead text" > > > > Last time I checked Monticello used a format called mcz which is nothing > more than a zip file containing st files, which are as you call it "dead > text" files. Also I would like to remind you that git is used by the CUIS > smalltalk to version control their images, I thought images are live code. > > > > Personally I dont see the diffirence between live and dead text. Its > just text to me. The VM is the one that makes it live anyway. > > Yes and no. > > If git compares two versions, it does not understand what is in it. > > When Monticello compares versions, it knows about classes, methods, > inheritance, > it can explain diffs in the same structured (browsable) form that you > wrote them. > > Putting Smalltalk in plain text files can be done, has been done, and was > not successful, because you lose something essential by leaving the > environment. > > The island argument is also a bit too easy: any platform can be seen as an > island that needs to integrate with others, there are degrees of openness. > Your Blender or Python are islands too, just like SAP, Microsoft and > Oracle. Some connections/interfaces are easy, some are hard(er). It all > depends on your position. > > When have you last looked at the source code of git ? > > And be honest, do you find git always easy to use ? > > > On Tue, Jan 26, 2016 at 5:09 PM Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > > > On 26 Jan 2016, at 15:59, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > > > To be fair my experience with pharo and git have been not always > smooth either. I have the VM crashing again and again completely randomly > when it was trying to pull SmaCC as dependency for my project Ephestos, had > to drop SmaCC and moving my python type parsing at python side. > > > > > > But I find it ironic someone using Monticello, trying to equate git > with dark ages, you cant get more dark ages than monticello, frankly. No > offense to people who made it , its great that is in there but its full of > problems and bad designs and cant even begin to be compared with Github and > GIT GUI clients. Monticello is according to my personal opinion by far the > worst tool of Pharo. > > > > No it is not. It is a version management system that understands our > object and code model, a system that we control. Git just manages blobs, > text files at best. Dead text. > > > > (This does not mean it is perfect, nor that it cannot improve, nor that > we should not improve our git integration.) > > > > > On Tue, Jan 26, 2016 at 4:51 PM Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > > > 2016-01-26 15:11 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > > > NorbertHartl wrote > > > > - I need to use BaselineOf instead of ConfigurationOf. Thus you > cannot use > > > > Versionner anymore > > > > > > Unfortunately. This is the biggest drag for me after switching all my > > > personal projects to git (GitHub for public and BitBucket for > private). I > > > had gotten spoiled by Versionner and hand-editing MetaC artifacts > feels like > > > going back to the dark ages :/ > > > > > > Well, I guess copying the baselines generated by Versionner into a > BaselineOf is probably a way to do it. > > > > > > Thierry > > > > > > > > > > > > > > > ----- > > > Cheers, > > > Sean > > > -- > > > View this message in context: > http://forum.world.st/Pharo-git-workflow-tp4874067p4874221.html > > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > > > > > >

Jan. 26, 2016