Re: [Pharo-users] diff'ing with metacello
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. 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] Morphic component to display images/pictures
have a look at the solution of the challenge 2 or 3 in the mooc :) On Thu, Mar 30, 2017 at 3:37 PM, Stephan Eggermont wrote: > On 30/03/17 13:24, Peter Uhnak wrote: > >> do we have a Morphic/Brick/whatever component for displaying >> pictures/images in Pharo? >> > > You can combine something with ImageMorph, ImagePreviewMorph, Form and > TransformMorph. I don't know about mousewheel support, I vaguely remember > something about mousewheel events being tranformed, and > forgot if that was vm- or image-side. > > > 1) zooming with mousewheel (now it scrolls vertically) >> 2) dragging the image around to scroll both vertically and horizontally >> (now I have to use manually the scrollbars) >> 3) ideally also buttons like "show 1:1 size", "show fit to window" >> > > > >
Re: [Pharo-users] PetitParser question parsing HTML meta tags
On 03/30/2017 10:58 AM, PAUL DEBRUICKER wrote: > 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. This looks like a job for the ordered choice operator. Perhaps something very roughly like this... descTag := nameDescTag / httpDescTag. nameDescTag := 'name=' , descAnyCase. httpDescTag := 'http-equiv=' , descAnyCase. descAnyCase := 'description' asParser / 'Description' asParser. And so on. HTH. Regards, -Martin
Re: [Pharo-users] type checking in Smalltalk
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
[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 := ' #'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
2017-03-30 16:03 GMT+02:00 Marc Hanisch via Pharo-users < pharo-users@lists.pharo.org>: > It is advised not to use the message isKindOf: in applications. > > I do understand that it is not a good idea to do different operations > depending on the kind of an object in one method. But in my (Javascript) > production code I do a lot of checking if an argument to a function is > "instanceof" someObject. When it is not the expected type of object, an > exception is thrown. I do this to ensure that someone (=another developer) > does not by accident passes a wrong type into my method. > > Reading this, I realized, that I never saw such type-checking in Pharo > production code. > In Pharo you will got DNU error automatically when object will receive message which it *d*oes *n*ot *u*nderstands. Then Pharo will show debugger to investigate and fix the problem. This is called dynamic typing and I guess JS will do something similar. So I wonder why you need custom error when program breaks types.
Re: [Pharo-users] type checking in Smalltalk
Hi Marc, > 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? I have carefully studied the topic of type checking in the past. I came to the conclusion that type errors are too easy to fix to justify a support in the language. There are always exceptions, for example, if you wish to provide guaranties and proof on some aspect of the language, interesting to hardware driver developers and critical software developers. In that case, you may want to have type annotation, maybe. But all in all, static type checking is more a distraction than a real benefit for practitioners in my opinion. Cheers, Alexandre
Re: [Pharo-users] type checking in Smalltalk
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. Instead of adding a test method, there are also empty implementations or ones that return self or an appropriate null-value. Stephan
Re: [Pharo-users] diff'ing with metacello
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] diff'ing with metacello
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?? cheers -ben
[Pharo-users] type checking in Smalltalk
--- Begin Message --- 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 ;-) In Pharo By Example 5, Page 308, in the Chapter "Introspection", it is written: "Although these features (type inspection) are especially useful for imple- menting development tools, they are normally not appropriate for typical applications. Asking an object for its class, or querying it to discover which messages it understands, are typical signs of design problems, since they violate the principle of encapsulation." It is advised not to use the message isKindOf: in applications. I do understand that it is not a good idea to do different operations depending on the kind of an object in one method. But in my (Javascript) production code I do a lot of checking if an argument to a function is "instanceof" someObject. When it is not the expected type of object, an exception is thrown. I do this to ensure that someone (=another developer) does not by accident passes a wrong type into my method. 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? Thanks for any advice :-) Marc --- End Message ---
Re: [Pharo-users] Morphic component to display images/pictures
On 30/03/17 13:24, Peter Uhnak wrote: do we have a Morphic/Brick/whatever component for displaying pictures/images in Pharo? You can combine something with ImageMorph, ImagePreviewMorph, Form and TransformMorph. I don't know about mousewheel support, I vaguely remember something about mousewheel events being tranformed, and forgot if that was vm- or image-side. 1) zooming with mousewheel (now it scrolls vertically) 2) dragging the image around to scroll both vertically and horizontally (now I have to use manually the scrollbars) 3) ideally also buttons like "show 1:1 size", "show fit to window"
[Pharo-users] Morphic component to display images/pictures
Hi, do we have a Morphic/Brick/whatever component for displaying pictures/images in Pharo? The "best" I found was GTInspector extension on PNG files, which provides scrollbars, however I would like to also have: 1) zooming with mousewheel (now it scrolls vertically) 2) dragging the image around to scroll both vertically and horizontally (now I have to use manually the scrollbars) 3) ideally also buttons like "show 1:1 size", "show fit to window" Do we have something like that? Thanks, Peter
