Re: [Pharo-users] diff'ing with metacello
2017-03-31 8:16 GMT+02:00 Siemen Baader : > Ok. So it is a missing feature. I will do individual diff'ing on versions > of the package that contains the method under concern instead. This is > after all not different from a git repo that uses eg a package.json file to > include external projects. > One of the thing that can be done is to temporarily copy all the versions concerned into a Git-based repository with Iceberg or GitFileTree, and then sees if git can provides a better diff, or even a git blame ability. I've done that multiple times... copy multiple versions in a repo, study the diff, and then just throw it away. Thierry > > Thanks for enlightening me! > > Siemen > > On Thu, Mar 30, 2017 at 4:57 PM, Thierry Goubier < > thierry.goub...@gmail.com> wrote: > >> >> >> 2017-03-30 16:42 GMT+02:00 Ben Coman : >> >>> On Thu, Mar 30, 2017 at 2:58 PM, Siemen Baader >>> wrote: >>> > Below is a fileout of 'ConfigurationOfPharoJS'. I download new >>> releases of >>> > PharoJS as they become available. Recently I found a regression - a >>> method >>> > 'PjApplication class >> playgroundWithoutLaunch' did not work any >>> more. What >>> > I wanted to do was to revert the whole project to an earlier version >>> until >>> > the method worked again - then look for the code that has been changed >>> > between releases and find the bug. >>> > >>> > In practice, even the earliest version (version 1.0 - method >>> #version10) did >>> > have the bug and I could not roll back the project to earlier release >>> states >>> > because there is no metadate for them. But I'd still like to learn how >>> to do >>> > it, so let's just say I want to compare version 1.2 and 1.3: >>> > >>> > version12: spec >>> > >>> > >>> > version13: spec >>> > >>> > >>> > >>> > I hope this makes sense. Thanks for helping me understand! >>> >>> You can only directly diff the Configurations themselves. >>> I fairly sure you can't auto-diff the packages loaded by each >>> configuration. >>> This is a missing feature. It would be nice to have something like >>> the merge-diff, >>> but there are probably other priorities. Maybe the new git workflow >>> will open some possibilities?? >>> >> >> If you have a project-oriented way of committing to git (you commit both >> the configuration and all the packages in one commit), then diffing via git >> would work. >> >> Current status on that feature is: >> >> - BaselineOf and all related packages save in one commit can be done with >> GitFileTree. I added an API for that and made a few experiments by >> organising and saving projects via the Metacello registry (with GUI >> support). I rolled back that extension in AltBrowser and I will reimplement >> it soon in a different, better way. >> >> - Iceberg ? >> >> - ConfigurationOf ? The approach of storing a configurationOf inside a >> meta repository makes implementing that harder. >> >> Now, I think the tools would probably be able to get that to work over >> Monticello with few changes, but they are a tad complex to implement, as in >> loading two different configurationsOf and resolving related packages >> (without loading them), and then changing the diff viewer to project all >> differences between all classes of the two groups of packages. One thing to >> remember is that complete packages, in multiple versions, can be loaded >> simultaneously as Monticello models without disrupting the code currently >> loaded and active in the image, as when you "browse" a Monticello package >> on disk. >> >> Thierry >> >> >>> >>> cheers -ben >>> >>> >> >
Re: [Pharo-users] type checking in Smalltalk
In other words: don't ask - tell. Instead of writing something like: object isSomething ifTrue: [ object doSomething ] ifFalse: [ object doSomethingElse ] just write it: object doSomething that gives you much less code bloat, and much clear view of your intent(s) and even in case of exception , you can always interpret DNU as "object are missing feature, you asked for", which is again, reveals your intent. Also things like: object isSomething ifTrue: [ self doSomethingWith: object ] ifFalse: [ self doSomethingElseWith: object ] in general considered as anti-pattern, because you basically implementing polymorphic behavior in wrong place i.e. in code that using object, instead of code that belongs to the object itself. On 31 March 2017 at 03:05, Ben Coman wrote: > > > On Thu, Mar 30, 2017 at 11:06 PM, Stephan Eggermont > wrote: > > On 30/03/17 16:03, Marc Hanisch via Pharo-users wrote: > >> > >> Reading this, I realized, that I never saw such type-checking in > >> Pharo production code. So the question is, what are recommended > >> design principles for that problem in Smalltalk? Do you use what is > >> called duck typing? > > > > > > Normally I'm not interested in what an object is, but what it can do. > > So a test on #respondsTo: can tell me if the object knows how to do > > something. > > > > In smalltalk, I can add methods to existing classes, so there are a lot > of > > extension methods on Object isXYZ, returning false. Morph returns true to > > isMorph, so all subclasses of Morph can be recognized that way. > > Many people also technically frown on isXYZ is a similar way to isKindOf:, > but it is a lesser evil and pragmatically is used reasonably often. > > > > > Instead of adding a test method, there are also empty implementations > > Like this, what you can do is refactor that guarded code into a method > #myAction > and add Object>>myAction which throws the exception. > Thus you condense multiple condition statements into > one location and your application code becomes much cleaner. > > Object may end up loaded with a lot of methods not of interest to every > object, > but the trade-off of cleaner application code is generally worth it. > > btw, Here you start to see how using Pharo/Smalltalk "changes the way you > think about programming". > > Further, the exception thrown by Object>>myAction > should signal the error on a custom error object, similar to ZeroDivide > for example. > > > > or ones that return self or an appropriate null-value. > > Within your framework where you control all the objects > the Null-object pattern is probably the cleanest OO approach, > but it can't control what the user passes across the public API. > https://en.wikipedia.org/wiki/Null_Object_pattern > > btw, you can search null-object pattern in Spotter using " Null #c " > > > cheers -ben > > -- Best regards, Igor Stasenko.
[Pharo-users] PetitParser question parsing HTML meta tags
its easier this way (still in form of a script): parseHtmlPageForDescription: htmlString | parser endParser metaParser descriptionParser contentParser res1Parser res2Parser quoteParser nonQuoteParser | metaParser := ' parser := (metaParser, res1Parser, contentParser, res2Parser, endParser) end ==> [:nodes| Array with: (nodes at: 2) inputValue with: (nodes at: 4) inputValue ]. ^parser parse: htmlString. "self parseHtmlPageForDescription: self htmlString1 self parseHtmlPageForDescription: self htmlString2 self parseHtmlPageForDescription: self htmlString3 " with htmlString1 ^'' etc.. you may want to read http://www.lukas-renggli.ch/blog/petitparser-1 good luck Hartmut This is kind of a "I'm tired of thinking about this and not making much progress for the amount of time I'm putting in question" but here it is: I'm trying to parse descriptions from HTML meta elements. I can't use Soup because there isn't a working GemStone port. I've got it to work with the structure: and but I'm running into instances of: and and am having trouble adapting my parsing code (such as it is). The parsing code that addresses the first two cases is: parseHtmlPageForDescription: htmlString | startParser endParser ppStream descParser result text lower str doubleQuoteIndex | lower := 'escription' asParser. startParser := ' #'second'. result := descParser parse: ppStream. text := (result inject: (WriteStream on: String new) into: [ :stream :char | stream nextPut: char. stream ]) contents trimBoth. str := text copyFrom: (text findString: 'content=') + 9 to: text size. doubleQuoteIndex := 8 - ((str last: 7) indexOf: $"). ^ str copyFrom: 1 to: str size - doubleQuoteIndex I can't figure out how to change the startParser parser to accept the second idiom. And maybe there's a better approach altogether. Anyway. If anyone has any ideas on different approaches I'd appreciate learning them. Thanks for giving it some thought Paul -- signatur Hartmut Krasemann Königsberger Str. 41 c D 22869 Schenefeld Tel. 040.8307097 Mobil 0171.6451283 krasem...@acm.org
[Pharo-users] Pharo with Google Realtime database
--- Begin Message --- Hello everybody, I developed an Android app. And the server of the application is written in Pharo. Google Realtime database is a NoSQL database which is very good for synchronization with android apps. I want to add data to this database from my Pharo app. And to do this I have to use a Rest Api. The rest api is existing for other languages like Php (Firebase-php), Python, Java, Go, etc. I want to know if this api is existing for Pharo? Thanks, Asbath --- End Message ---
Re: [Pharo-users] Pharo with Google Realtime database
There isn't any Firebase database driver for it. I used Firebase database and auth briefly for a JS/HTML only app, and I pulled the data using plain ZnClient to access the REST API. Regards, Esteban A. Maringolo 2017-03-31 8:13 GMT-03:00 Asbath Sama biyalou via Pharo-users : > > > -- Mensaje reenviado -- > From: Asbath Sama biyalou > To: Pharo users users > Cc: > Bcc: > Date: Fri, 31 Mar 2017 12:13:06 +0100 > Subject: Pharo with Google Realtime database > Hello everybody, > > I developed an Android app. And the server of the application is written > in Pharo. > > Google Realtime database is a NoSQL database which is very good for > synchronization with android apps. I want to add data to this database > from my Pharo app. And to do this I have to use a Rest Api. The rest api > is existing for other languages like Php (Firebase-php), Python, Java, > Go, etc. > > I want to know if this api is existing for Pharo? > > > Thanks, > > > Asbath > > >
Re: [Pharo-users] type checking in Smalltalk
--- Begin Message --- Thanks for that many responses! :-) I think I get the picture! In JavaScript I do that type checking because although I get an error, when requesting a method that is not defined, I do not get one when requesting or setting a property that does not exists. Much more worse in PHP before version 7.0 I get an error, which can not be handled by try / except - but not an exception object. Great to know that I can keep the code clean in Smalltalk as I get an exception every time I try to send a message that is unknow to the receiver! Best regards, Marc 2017-03-31 12:31 GMT+02:00 Igor Stasenko : > In other words: don't ask - tell. > Instead of writing something like: > > object isSomething ifTrue: [ object doSomething ] ifFalse: [ object > doSomethingElse ] > > just write it: > object doSomething > > that gives you much less code bloat, and much clear view of your intent(s) > and even in case of exception , you can always interpret DNU as "object > are missing feature, you asked for", which is again, reveals your intent. > > Also things like: > > object isSomething ifTrue: [ self doSomethingWith: object ] ifFalse: [ > self doSomethingElseWith: object ] > > in general considered as anti-pattern, because you basically implementing > polymorphic behavior in wrong place i.e. in code that using object, instead > of code that belongs to the object itself. > > > On 31 March 2017 at 03:05, Ben Coman wrote: > >> >> >> On Thu, Mar 30, 2017 at 11:06 PM, Stephan Eggermont >> wrote: >> > On 30/03/17 16:03, Marc Hanisch via Pharo-users wrote: >> >> >> >> Reading this, I realized, that I never saw such type-checking in >> >> Pharo production code. So the question is, what are recommended >> >> design principles for that problem in Smalltalk? Do you use what is >> >> called duck typing? >> > >> > >> > Normally I'm not interested in what an object is, but what it can do. >> > So a test on #respondsTo: can tell me if the object knows how to do >> > something. >> > >> > In smalltalk, I can add methods to existing classes, so there are a lot >> of >> > extension methods on Object isXYZ, returning false. Morph returns true >> to >> > isMorph, so all subclasses of Morph can be recognized that way. >> >> Many people also technically frown on isXYZ is a similar way to isKindOf:, >> but it is a lesser evil and pragmatically is used reasonably often. >> >> > >> > Instead of adding a test method, there are also empty implementations >> >> Like this, what you can do is refactor that guarded code into a method >> #myAction >> and add Object>>myAction which throws the exception. >> Thus you condense multiple condition statements into >> one location and your application code becomes much cleaner. >> >> Object may end up loaded with a lot of methods not of interest to every >> object, >> but the trade-off of cleaner application code is generally worth it. >> >> btw, Here you start to see how using Pharo/Smalltalk "changes the way you >> think about programming". >> >> Further, the exception thrown by Object>>myAction >> should signal the error on a custom error object, similar to ZeroDivide >> for example. >> >> >> > or ones that return self or an appropriate null-value. >> >> Within your framework where you control all the objects >> the Null-object pattern is probably the cleanest OO approach, >> but it can't control what the user passes across the public API. >> https://en.wikipedia.org/wiki/Null_Object_pattern >> >> btw, you can search null-object pattern in Spotter using " Null #c " >> >> >> cheers -ben >> >> > > > -- > Best regards, > Igor Stasenko. > --- End Message ---
Re: [Pharo-users] New chapter for new book
--- Begin Message --- Wow, thats amazing! Thank you Stephane! 2017-03-31 15:51 GMT+02:00 Stephane Ducasse : > Hi > > I attached a new chapter for my forthcoming book. > > Stef > > --- End Message ---
Re: [Pharo-users] type checking in Smalltalk
Marc, you should definitely go and understand method lookup and handling of unknown messages. This is the fun part of Smalltalk ;-) Just don't overuse it, because you can do things that are so cool you won't be able to understand your own code any more ;-) Joachim -- --- Objektfabrik Joachim Tuchel mailto:jtuc...@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
Re: [Pharo-users] type checking in Smalltalk
On Thu, Mar 30, 2017 at 5:04 PM Marc Hanisch via Pharo-users < pharo-users@lists.pharo.org> wrote: > Hello, > > I have a question which is more related to software engineering than to > Pharo, but I hope that someone can give me an useful hint ;-) > > > Thanks for any advice :-) > Marc > There are three schools of thought Static programming , Dynamic programming and Hybrid Programming *School of Static Programming * The school of Static Programming which has been originating from compiled languages (turn code from source code to machine code before execution) it follows a static approach to the code. This means everything is clearly predefined, planned ahead and follows strict rules. *Pros: * 1) because compilers have specific code that its intentions are clear its much easier for them to optimize performance, hence code tends to run much faster eg C code tends to be 100s to 1000s times faster than Python code 2) Certain bugs can be captured at compile time which makes code safer to deploy to client. The compiler usually can capture such bugs and display relevant warning and errors again because the compiler is more strict to what goes in and what gets out. *Cons:* 1) Changing code on the fly, while the code runs can be notorious hard to do because of these restrictions. This means it does not work well with coders that love to experiment and try new ideas on the fly. 2) Finding bugs also can be harder because of these restrictions, the coder cannot easily change code on the fly on execution and generally the programming language is much less forgiving not only when coding but also when trying to inspect code and debug it. 3) Overall design can be quite ugly in the shake of increased performance and safety and that may affect the design of code as well *School of Dynamic Programming* The school of Dynamic Programming originates from interpreted languages , though modern implementations have compilers that compile source code to byte code and an interpreter that converts byte code to machine code on execution. There is no need for planning ahead in dynamic coding, instead dynamic coding works on the basis of abstractions and its proud to be the father and mother of OOP. OOP is an abstraction based , dynamic coding workflow that dominates dynamic language and even modern statically compiled languages. *Pros:* 1) Code can change on the fly making coding much easier and beginner friendly 2) No need to plan ahead 3) more dynamic workflow also when debugging code that allows to interact and communicate with code real time *Cons:* 1) Performance is sacrificed, thats not obvious for code that executes at once but for code that repeats thousands to millions of times the slow downs depending on the implementation of the language can be anywhere between 10s of times to 1000s of times slower that a static language 2) Using the wrong data / object will not be easily reported beforehand and at times it can be hard to detect such problems. Other bugs can also be hard to be detected even under the use of helping tools that examine and evaluate code because of the generic nature of the code. *Hybrid Programming* Even though static languages give us static programming outside the box and dynamic languages give us dynamic programming outside the box, modern implementation allow for repetitively easily to mix these two workflows. Its also possible for the coder to implement his/her own features with a language. For example C language does not support OOP outside the box, but OOP implementations for C do exist most popular being GObjects used by the GTK+ library C++ and Java although statically typed languages support also more dynamic types through the use of templates and generics Dynamic languages also can come with a variety of tools that perform checks during runtime or even compile time. Also test driven development is very popular for performing this task allowing the coder to create code , launch with a single command thousands of tests and make sure his code passes even more strict guidelines than an average compiler for a statically compiled language. The catch however is that in both cases there are compromises, sub standard implementations and plain weird behavior. *Summary:* *There is no right and wrong, whether we talk about types or other features whether you will follow the dynamic school or the static school is up to you and you preferences.* Both approaches have pros and cons and both will make you waste time while coding. The future however looks more bright and promising for the dynamic school with the rise of AI. Compilers and developer tools in the future may be smarter not only detecting errors and common bugs but actually analyzing coder intentions and even coding philosophies. AI is already used for code analysis but its still on early stage but is none the less our very close future. Funny irony: The most popular scenario for future technology is quantum computing. Ha
Re: [Pharo-users] New chapter for new book
Awesome to see Pharo doing so great on documentation front, when I joined back in 2011 there was not even basic documentation now there so many new useful books that is fun to read like this one. Great work :) On Fri, Mar 31, 2017 at 5:06 PM Marc Hanisch via Pharo-users < pharo-users@lists.pharo.org> wrote: > Wow, thats amazing! > > Thank you Stephane! > > 2017-03-31 15:51 GMT+02:00 Stephane Ducasse : > > Hi > > I attached a new chapter for my forthcoming book. > > Stef > > >
[Pharo-users] Voyage, DateAndTime and UTC
Hi, As far as I see when I store a DateAndTime with local time, "2017-03-31T17:10:46.137086+02:00", then I fetch it back, I got an UTC DateAndTime "2017-03-31T15:10:46.137086+00:00". Am I doing something wrong or do I need to use a mongo description to correct that. But wait, even so, I will not know what was the initial local time. How do you usually deal such issue? Thanks Hilaire -- Dr. Geo http://drgeo.eu
Re: [Pharo-users] New chapter for new book
This is not exactly true. Pharo By Example was already there, and preceeded by Squeak By Exemple, which the former is an adaptation. Le 31/03/2017 à 16:47, Dimitris Chloupis a écrit : > when I joined back in 2011 there was not even basic documentation -- Dr. Geo http://drgeo.eu
Re: [Pharo-users] Voyage, DateAndTime and UTC
Hi, > Am 31.03.2017 um 17:16 schrieb Hilaire : > > Hi, > > As far as I see when I store a DateAndTime with local time, > "2017-03-31T17:10:46.137086+02:00", then I fetch it back, I got an UTC > DateAndTime "2017-03-31T15:10:46.137086+00:00". > > Am I doing something wrong or do I need to use a mongo description to > correct that. But wait, even so, I will not know what was the initial > local time. > > How do you usually deal such issue? > it's a pitty. BSON only supports a date type which is date and time in UTC. So the offset information is stripped off and that is the reason why you get it this way. I fell over this a lot. Especially when you use a local midnight DateAndTime store it in mongo, read it and then do #asDate you will end up having one day before. Very annoying. I think we shouldn't store DateAndTime as BSON date. We should create a custom type that includes timezone offset information. Norbert
Re: [Pharo-users] type checking in Smalltalk
if you copy/paste something you should give a reference > On 31 Mar 2017, at 16:40, Dimitris Chloupis wrote: > > > > On Thu, Mar 30, 2017 at 5:04 PM Marc Hanisch via Pharo-users > wrote: > Hello, > > I have a question which is more related to software engineering than to > Pharo, but I hope that someone can give me an useful hint ;-) > > > Thanks for any advice :-) > Marc > > There are three schools of thought > Static programming , Dynamic programming and Hybrid Programming > > School of Static Programming > > The school of Static Programming which has been originating from compiled > languages (turn code from source code to machine code before execution) it > follows a static approach to the code. This means everything is clearly > predefined, planned ahead and follows strict rules. > > Pros: > > 1) because compilers have specific code that its intentions are clear its > much easier for them to optimize performance, hence code tends to run much > faster eg C code tends to be 100s to 1000s times faster than Python code > > 2) Certain bugs can be captured at compile time which makes code safer to > deploy to client. The compiler usually can capture such bugs and display > relevant warning and errors again because the compiler is more strict to what > goes in and what gets out. > > Cons: > > 1) Changing code on the fly, while the code runs can be notorious hard to do > because of these restrictions. This means it does not work well with coders > that love to experiment and try new ideas on the fly. > > 2) Finding bugs also can be harder because of these restrictions, the coder > cannot easily change code on the fly on execution and generally the > programming language is much less forgiving not only when coding but also > when trying to inspect code and debug it. > > 3) Overall design can be quite ugly in the shake of increased performance and > safety and that may affect the design of code as well > > School of Dynamic Programming > > The school of Dynamic Programming originates from interpreted languages , > though modern implementations have compilers that compile source code to byte > code and an interpreter that converts byte code to machine code on execution. > There is no need for planning ahead in dynamic coding, instead dynamic coding > works on the basis of abstractions and its proud to be the father and mother > of OOP. OOP is an abstraction based , dynamic coding workflow that dominates > dynamic language and even modern statically compiled languages. > > Pros: > 1) Code can change on the fly making coding much easier and beginner friendly > 2) No need to plan ahead > 3) more dynamic workflow also when debugging code that allows to interact and > communicate with code real time > > Cons: > > 1) Performance is sacrificed, thats not obvious for code that executes at > once but for code that repeats thousands to millions of times the slow downs > depending on the implementation of the language can be anywhere between 10s > of times to 1000s of times slower that a static language > > 2) Using the wrong data / object will not be easily reported beforehand and > at times it can be hard to detect such problems. Other bugs can also be hard > to be detected even under the use of helping tools that examine and evaluate > code because of the generic nature of the code. > > Hybrid Programming > > Even though static languages give us static programming outside the box and > dynamic languages give us dynamic programming outside the box, modern > implementation allow for repetitively easily to mix these two workflows. Its > also possible for the coder to implement his/her own features with a language. > > For example C language does not support OOP outside the box, but OOP > implementations for C do exist most popular being GObjects used by the GTK+ > library > > C++ and Java although statically typed languages support also more dynamic > types through the use of templates and generics > > Dynamic languages also can come with a variety of tools that perform checks > during runtime or even compile time. Also test driven development is very > popular for performing this task allowing the coder to create code , launch > with a single command thousands of tests and make sure his code passes even > more strict guidelines than an average compiler for a statically compiled > language. > > The catch however is that in both cases there are compromises, sub standard > implementations and plain weird behavior. > > Summary: > > There is no right and wrong, whether we talk about types or other features > whether you will follow the dynamic school or the static school is up to you > and you preferences. Both approaches have pros and cons and both will make > you waste time while coding. > > The future however looks more bright and promising for the dynamic school > with the rise of AI. Compilers and developer tools in the future may be
Re: [Pharo-users] Voyage, DateAndTime and UTC
Or just store as ISO8601 string. NorbertHartl wrote > Hi, > >> Am 31.03.2017 um 17:16 schrieb Hilaire < > hilaire@ > >: >> >> Hi, >> >> As far as I see when I store a DateAndTime with local time, >> "2017-03-31T17:10:46.137086+02:00", then I fetch it back, I got an UTC >> DateAndTime "2017-03-31T15:10:46.137086+00:00". >> >> Am I doing something wrong or do I need to use a mongo description to >> correct that. But wait, even so, I will not know what was the initial >> local time. >> >> How do you usually deal such issue? >> > it's a pitty. BSON only supports a date type which is date and time in > UTC. So the offset information is stripped off and that is the reason why > you get it this way. I fell over this a lot. Especially when you use a > local midnight DateAndTime store it in mongo, read it and then do #asDate > you will end up having one day before. Very annoying. > I think we shouldn't store DateAndTime as BSON date. We should create a > custom type that includes timezone offset information. > > Norbert -- View this message in context: http://forum.world.st/Voyage-DateAndTime-and-UTC-tp4940779p4940811.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] New chapter for new book
Marc the full book is available at: https://ci.inria.fr/pharo-contribution/view/Books/job/LearningObjectOrientedProgramming/lastSuccessfulBuild/artifact/build/book.pdf On Fri, Mar 31, 2017 at 4:05 PM, Marc Hanisch via Pharo-users < pharo-users@lists.pharo.org> wrote: > > > -- Forwarded message -- > From: Marc Hanisch > To: Any question about pharo is welcome > Cc: > Bcc: > Date: Fri, 31 Mar 2017 16:05:11 +0200 > Subject: Re: [Pharo-users] New chapter for new book > Wow, thats amazing! > > Thank you Stephane! > > 2017-03-31 15:51 GMT+02:00 Stephane Ducasse : > >> Hi >> >> I attached a new chapter for my forthcoming book. >> >> Stef >> >> > >
Re: [Pharo-users] type checking in Smalltalk
On Fri, 31 Mar 2017 at 19:13, Sven Van Caekenberghe wrote: > if you copy/paste something you should give a reference > I did not copy paste anything, 100 % mine. What part you think it's copy ?
Re: [Pharo-users] New chapter for new book
PBE was stuck in version 1.4 until we got to version 4 when I started updating it. So PBE 2 and 3 and most of 4 do not exist. Even PBE 5 is partial. On Fri, 31 Mar 2017 at 18:21, Hilaire wrote: > This is not exactly true. Pharo By Example was already there, and > preceeded by Squeak By Exemple, which the former is an adaptation. > > Le 31/03/2017 à 16:47, Dimitris Chloupis a écrit : > > when I joined back in 2011 there was not even basic documentation > > -- > Dr. Geo > http://drgeo.eu > > >
Re: [Pharo-users] New chapter for new book
--- Begin Message --- Thanks Stephane, I'm digging into Pharo and I'm reading the books like a sponge ;-) Great work and thanks for the link! Marc Am 31.03.2017 19:18 schrieb "Stephane Ducasse" : > Marc the full book is available at: > > https://ci.inria.fr/pharo-contribution/view/Books/job/ > LearningObjectOrientedProgramming/lastSuccessfulBuild/ > artifact/build/book.pdf > > On Fri, Mar 31, 2017 at 4:05 PM, Marc Hanisch via Pharo-users < > pharo-users@lists.pharo.org> wrote: > >> >> >> -- Forwarded message -- >> From: Marc Hanisch >> To: Any question about pharo is welcome >> Cc: >> Bcc: >> Date: Fri, 31 Mar 2017 16:05:11 +0200 >> Subject: Re: [Pharo-users] New chapter for new book >> Wow, thats amazing! >> >> Thank you Stephane! >> >> 2017-03-31 15:51 GMT+02:00 Stephane Ducasse : >> >>> Hi >>> >>> I attached a new chapter for my forthcoming book. >>> >>> Stef >>> >>> >> >> > --- End Message ---
Re: [Pharo-users] type checking in Smalltalk
> On 31 Mar 2017, at 19:38, Dimitris Chloupis wrote: > > > On Fri, 31 Mar 2017 at 19:13, Sven Van Caekenberghe wrote: > if you copy/paste something you should give a reference > > > I did not copy paste anything, 100 % mine. What part you think it's copy ? Ah, sorry then, the formatting seemed to suggest it came from somewhere else. BTW, I don't think the hybrid part is a real thing. Although I understand that static typed languages like C, C++, Java and so many others have their place and use, people in those languages spend an awful amount of time and code dealing with the types they love so much. The modern static languages with all their magic are even worse. And even in a nice static typed program that compiles with no warnings, there are still dynamic errors lurking everywhere. The world cannot be defined in a static way. The dynamic type errors that you get in Pharo during development are 95% plain logic errors, once you fix those and write some unit tests, a Pharo program is just as stable and reliable as anything else that is well written, tested and debugged. And I love Igor's "Don't ask, tell" idea - right on target. Anyway, that is my personal opinion, I don't want to convince you. Sven
Re: [Pharo-users] Voyage, DateAndTime and UTC
Thanks for the idea. For me it is a bug[2], like the other one related to Date persistency, saved as DateAndTime, then shifting you one day[1]. Hilaire [1] https://github.com/pharo-nosql/voyage/issues/88 [2] https://github.com/pharo-nosql/voyage/issues/89 Le 31/03/2017 à 18:54, Paul DeBruicker a écrit : > Or just store as ISO8601 string. > -- Dr. Geo http://drgeo.eu
Re: [Pharo-users] type checking in Smalltalk
Hehe yeah I love nice formatting :) You don't need to convince me , I prefer coding dynamically Ironically enough is the static that is not a real thing anymore. I am coding C++ and Unreal uses templates for pretty much everything. Templates the equivalent of dynamic types, kinda. However when performance is concerned anything dynamic must go, which in C++ means templates and smart pointers. One for dynamic types and the other for dynamic memory management. Generally however templates and generics are super popular and coders are frowned upon if they do not use them because falling back to pure static coding is considered bad coding practice. C++ is on route of becoming even more hybrid, the new hot potato being modules a replacement to header files , similar to Python modules. It was to be included in the next iteration of C++ but was postponed. Probably will get included in the one after the next. In Python a module is a source code file that is treated as an object. So a global variable is equivalent to class variable, the source file being the class. If the module is a package (file folder) then it's class variables are the sub modules. Nowadays people use static languages not because they want to but because the have to for legacy code and performance reasons. Still modern projects usually mix dynamic with static languages. The static plays the role of the kernel providing high performance the dynamic the role of easy to use , beginner friendly, scripting interface. Java and C# support out of the box any dynamic language out there. So the lines nowadays are extremely blurry. It's 2017 , great time to live in when you can choose among so many choices. On Fri, 31 Mar 2017 at 21:35, Sven Van Caekenberghe wrote: > > > On 31 Mar 2017, at 19:38, Dimitris Chloupis > wrote: > > > > > > On Fri, 31 Mar 2017 at 19:13, Sven Van Caekenberghe > wrote: > > if you copy/paste something you should give a reference > > > > > > I did not copy paste anything, 100 % mine. What part you think it's copy > ? > > Ah, sorry then, the formatting seemed to suggest it came from somewhere > else. > > BTW, I don't think the hybrid part is a real thing. > > Although I understand that static typed languages like C, C++, Java and so > many others have their place and use, people in those languages spend an > awful amount of time and code dealing with the types they love so much. The > modern static languages with all their magic are even worse. And even in a > nice static typed program that compiles with no warnings, there are still > dynamic errors lurking everywhere. The world cannot be defined in a static > way. > > The dynamic type errors that you get in Pharo during development are 95% > plain logic errors, once you fix those and write some unit tests, a Pharo > program is just as stable and reliable as anything else that is well > written, tested and debugged. > > And I love Igor's "Don't ask, tell" idea - right on target. > > Anyway, that is my personal opinion, I don't want to convince you. > > Sven >
Re: [Pharo-users] Smacc debugger
Hi thierry Where can I find a documentation of +, * ? in the grammar (and especially how to manage the production)? And indeed they do not work in the Moose version. I think that if +, *, ?, ( ) are working in the grammar it is an important addition to Smacc. Because I found it right now verbose compare to ANTLR Stef On Wed, Mar 29, 2017 at 7:19 PM, Thierry Goubier wrote: > > > 2017-03-29 18:21 GMT+02:00 Stephane Ducasse : > >> So I browsed the mailing-list and I foind the mail of thierry saying that >> there is no difference. >> I will try to tools in moose then. >> > > Probably: the +, *, ?, ( ) in the grammar don't work anymore. As I told > you: very few differences. > > >> On Wed, Mar 29, 2017 at 6:07 PM, Stephane Ducasse < >> stepharo.s...@gmail.com> wrote: >> >>> Ok I should say that I do not understand the differences and why there >>> are two versions of Smacc. >>> So I will stop maintaining the tutorial because now may be I should >>> revert what I wrote. >>> I was too stupid to do it in fact I should focus on my stuff and nothing >>> else. >>> This saddens me a lot. >>> We are a small community and we split ourselves into little chunks. >>> I do not get why there is no notion of economy and sharing in our >>> culture. >>> >> > Thierry > > >> >>> Stef >>> >>> >>> >>> On Wed, Mar 29, 2017 at 2:30 PM, Tudor Girba >>> wrote: >>> Hi, > On Mar 28, 2017, at 11:50 AM, Stephane Ducasse < stepharo.s...@gmail.com> wrote: > > OK > I loaded Smacc from github as mentioned by thierry. > > Metacello new > baseline: 'SmaCC'; > repository: 'github://ThierryGoubier/SmaCC'; > load > > Are there two configurationOfSmacc? > May be we should only have one no? > > I have the impression that even thierry and jason working heavily with Smacc do not know that. > And we should not force them to use Moose. At least we do not have to win > anything with it. I did not mean to force anyone to use Moose. I just said it is already loaded there, in case you use it. Moose relies on the ConfigurationOfSmaCC maintained by John. Thierry has another repository that he created before John moved his work to Pharo. But, now that he does work with Pharo Moose relies on his version. Cheers, Doru > > Stef > > On Mon, Mar 27, 2017 at 6:31 PM, Tudor Girba wrote: > They come with the ConfigurationOfSmaCC which is already in the Moose image. > > Doru > > > > On Mar 27, 2017, at 4:52 PM, Stephane Ducasse < stepharo.s...@gmail.com> wrote: > > > > Hi > > > > where can I load the Smacc gt extension and debugger extensions? > > > > Stef > > -- > www.tudorgirba.com > www.feenk.com > > "Speaking louder won't make the point worthier." > > > -- www.tudorgirba.com www.feenk.com "There are no old things, there are only old ways of looking at them." >>> >> >
Re: [Pharo-users] diff'ing with metacello
> One of the thing that can be done is to temporarily copy all the versions > concerned into a Git-based repository with Iceberg or GitFileTree, and then > sees if git can provides a better diff, or even a git blame ability Great tip, thanks, Thierry! -- Siemen > . I've done that multiple times... copy multiple versions in a repo, study > the diff, and then just throw it away. > > Thierry > >> >> Thanks for enlightening me! >> >> Siemen >> >> On Thu, Mar 30, 2017 at 4:57 PM, Thierry Goubier >> wrote: >>> >>> >>> 2017-03-30 16:42 GMT+02:00 Ben Coman : On Thu, Mar 30, 2017 at 2:58 PM, Siemen Baader wrote: > Below is a fileout of 'ConfigurationOfPharoJS'. I download new releases > of > PharoJS as they become available. Recently I found a regression - a > method > 'PjApplication class >> playgroundWithoutLaunch' did not work any more. > What > I wanted to do was to revert the whole project to an earlier version > until > the method worked again - then look for the code that has been changed > between releases and find the bug. > > In practice, even the earliest version (version 1.0 - method #version10) > did > have the bug and I could not roll back the project to earlier release > states > because there is no metadate for them. But I'd still like to learn how > to do > it, so let's just say I want to compare version 1.2 and 1.3: > > version12: spec > > > version13: spec > > > > I hope this makes sense. Thanks for helping me understand! You can only directly diff the Configurations themselves. I fairly sure you can't auto-diff the packages loaded by each configuration. This is a missing feature. It would be nice to have something like the merge-diff, but there are probably other priorities. Maybe the new git workflow will open some possibilities?? >>> >>> If you have a project-oriented way of committing to git (you commit both >>> the configuration and all the packages in one commit), then diffing via git >>> would work. >>> >>> Current status on that feature is: >>> >>> - BaselineOf and all related packages save in one commit can be done with >>> GitFileTree. I added an API for that and made a few experiments by >>> organising and saving projects via the Metacello registry (with GUI >>> support). I rolled back that extension in AltBrowser and I will reimplement >>> it soon in a different, better way. >>> >>> - Iceberg ? >>> >>> - ConfigurationOf ? The approach of storing a configurationOf inside a meta >>> repository makes implementing that harder. >>> >>> Now, I think the tools would probably be able to get that to work over >>> Monticello with few changes, but they are a tad complex to implement, as in >>> loading two different configurationsOf and resolving related packages >>> (without loading them), and then changing the diff viewer to project all >>> differences between all classes of the two groups of packages. One thing to >>> remember is that complete packages, in multiple versions, can be loaded >>> simultaneously as Monticello models without disrupting the code currently >>> loaded and active in the image, as when you "browse" a Monticello package >>> on disk. >>> >>> Thierry >>> cheers -ben >
Re: [Pharo-users] PetitParser question parsing HTML meta tags
You could use XMLHTMLParser from STHub PharoExtras/XMLParserHTML (supported on Pharo, Squak, and GS): descriptions := OrderedCollection new. (XMLHTMLParser parseURL: aURL) allElementsNamed: 'meta' do: [:each | ((each attributeAt: 'name') asLowercase = 'description' or: [(each attributeAt: 'http-equiv') asLowercase = 'description']) ifTrue: [descriptions addLast: (each attributeAt: 'content')]]. it accepts messy HTML and produces an XML DOM tree from it. > Sent: Thursday, March 30, 2017 at 1:58 PM > From: "PAUL DEBRUICKER" > To: "Any question about pharo is welcome" > Subject: [Pharo-users] PetitParser question parsing HTML meta tags > > This is kind of a "I'm tired of thinking about this and not making much > progress for the amount of time I'm putting in question" but here it is: > > > > I'm trying to parse descriptions from HTML meta elements. I can't use Soup > because there isn't a working GemStone port. > > I've got it to work with the structure: > > > > and > > > > > but I'm running into instances of: > > > > and > > > > > and am having trouble adapting my parsing code (such as it is). > > > The parsing code that addresses the first two cases is: > > > > parseHtmlPageForDescription: htmlString > | startParser endParser ppStream descParser result text lower str > doubleQuoteIndex | > lower := 'escription' asParser. > startParser := ' endParser := '>' asParser. > ppStream := htmlString readStream asPetitStream. > descParser := ((#'any' asParser starLazy: startParser , lower) > , (#'any' asParser starLazy: endParser)) ==> #'second'. > result := descParser parse: ppStream. > text := (result > inject: (WriteStream on: String new) > into: [ :stream :char | > stream nextPut: char. > stream ]) > contents trimBoth. > str := text copyFrom: (text findString: 'content=') + 9 to: text size. > doubleQuoteIndex := 8 - ((str last: 7) indexOf: $"). > ^ str copyFrom: 1 to: str size - doubleQuoteIndex > > > I can't figure out how to change the startParser parser to accept the second > idiom. And maybe there's a better approach altogether. Anyway. If anyone > has any ideas on different approaches I'd appreciate learning them. > > > Thanks for giving it some thought > > Paul >
Re: [Pharo-users] type checking in Smalltalk
On Sat, Apr 1, 2017 at 2:34 AM, Sven Van Caekenberghe wrote: > > > On 31 Mar 2017, at 19:38, Dimitris Chloupis > wrote: > > > > > > On Fri, 31 Mar 2017 at 19:13, Sven Van Caekenberghe > wrote: > > if you copy/paste something you should give a reference > > > > > > I did not copy paste anything, 100 % mine. What part you think it's copy > ? > > Ah, sorry then, the formatting seemed to suggest it came from somewhere > else. > > BTW, I don't think the hybrid part is a real thing. > > Although I understand that static typed languages like C, C++, Java and so > many others have their place and use, people in those languages spend an > awful amount of time and code dealing with the types they love so much. The > modern static languages with all their magic are even worse. And even in a > nice static typed program that compiles with no warnings, there are still > dynamic errors lurking everywhere. The world cannot be defined in a static > way. > > The dynamic type errors that you get in Pharo during development are 95% > plain logic errors, once you fix those and write some unit tests, a Pharo > program is just as stable and reliable as anything else that is well > written, tested and debugged. > > And I love Igor's "Don't ask, tell" idea - right on target. > This would make a good name for a book on OO. cheers -ben > > Anyway, that is my personal opinion, I don't want to convince you. > > Sven >
