July 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About Cocoa delegate

by Mark Bestley

You don't have to write the check it is just defensive programming you can just do -(void)someMethod { if ( [delegate operationShouldProceed] ) { // do something appropriate } } then if the delegate does not have operationShouldProceed you get a selector not found error - which will crash the program. So similar to smalltalk except that would get a debugger here. So depends how certain you have a good delegate or if there is something you can do if you don't. Mark On 16/07/2014 09:58, stepharo wrote: > I found strange to force user to write > > Before invoking a delegation method, make sure the delegate implements > it by sending it a > > respondsToSelector: message. > > Cocoa Fundamentals Guide (TP40002974 6.0.0) > > - (void)someMethod { > > if ( [delegate respondsToSelector:@selector(operationShouldProceed)] ){ > > if ( [delegate operationShouldProceed] ) { > // do something appropriate > > } } > > } > > I'm reading also on bindings (could be like valueHolder) and targetAction. > I think that I will have to read that several times :) > > https://developer.apple.com/legacy/library/documentation/Cocoa/Conceptual/C… > > Stef > > Cocoa Fundamentals Guide (TP40002974 6.0.0) > On 16/7/14 10:48, stepharo wrote: >> Hi >> >> In the quest for a better UI framework :), I was re rereading about >> delegate in Cocoa. >> A delegating object will delegate certain operations to a delegate >> object (check the attachment). >> Now I was wondering why this is not a simple delegation they wrote: >> >> The delegating object sends a message only if the delegate implements >> the method. It makes this discovery by invoking the NSObject method >> respondsToSelector: in the delegate first. >> >> Cocoa Fundamentals Guide (TP40002974 6.0.0) >> > -- Mark

July 16, 2014

Re: [Pharo-dev] [ANN] Ephestos - Using and Coding Blender from inside Pharo

by Damien Cassou

On Tue, Jul 15, 2014 at 11:09 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > > The goal is to expose Blender coders to the power of Pharo and Pharo to the > power of Blender. As you can imagine the potential is huge but I rather talk > what Ephestos can do already. That's great kilon! I can't wait to see how far you could go with that. I hope you plan to use Pharo syntax instead of plain string for the messages. A message like this: "bpy.data.objects["Cube"].location = (0.0, 0.0, 0.0)" could be written like that: (EphestosMessage bpy data objects: 'Cube') location: (EphestosLocation x: 0 y: 0 z: 0) or something similar -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

July 16, 2014

Re: [Pharo-dev] [ANN] Ephestos - Using and Coding Blender from inside Pharo

by Ben Coman

I don't have time to play, but this looks very very cool. At a minimum, its a great demonstration of Pharo/Smalltalk playing-well-with-others. Some feedback on the video presentation, zooming in on the workspace to make the text more readable in low-def video streams, then zooming out just before it is executed would be useful. cheers -ben kilon alios wrote: > Its far from production ready but I am too excited to keep to myself. > I present to you Ephestos. > > Ephestos is a socket bridge that communicates with Blender the most > popular and most powerful open source 3d application. > > http://www.blender.org/ > > The goal is to expose Blender coders to the power of Pharo and Pharo > to the power of Blender. As you can imagine the potential is huge but > I rather talk what Ephestos can do already. > > Even though Ephestos is in total less than 200 lines of code it can > already communicate with blender and affect blender properties. > Blender properties are basically instance variables for any kind of > blender object, 3d object, material, textures etc So already you can > affect a huge deal of blender . > > Unfortunately Blender operators seem to crash Blender , probably I am > doing something stupid that I will fix. Blender operators are for > performing blender actions so they are very important. > > I have made a simple video demo of it that can be watched here > > https://www.youtube.com/watch?v=8igk9DoY6PU&feature=youtu.be > <https://www.youtube.com/watch?v=8igk9DoY6PU&feature=youtu.be> > > To use it you need first the Blender addon which can be found here > > https://github.com/kilon/pyEphestos > > The code should be inside a folder named "pyEphestos" and placed in > Blender addons directory which is located for Macos in Application > Support/Blender/VersionsOfBlender/scripts/addons and in Windows should > be in App Data/Roaming/..... or you can place it inside the blender > folder in similar sub directory > > You also need the Pharo code which can be found here > > http://www.smalltalkhub.com/#!/~kilon/Ephestos/ > <http://www.smalltalkhub.com/#%21/%7Ekilon/Ephestos/> > > As I said it is far from production ready , but it works. > > The good news is that the socket communication is blazing fast, at > least compared to what I expected. I was able to perform 1000 > connections under a second. And each connection carries a 1024 bytes > messages , thats a lot of code. Should be possible to pass thousands > of lines of code under a second to Blender. > > My only worry is blender itself since it tends to be very crashy in > the areas I am pushing. > > By the way Always press esc after you enable Ephestos in Blender to > close the socket or else it wont free it and next time you wont be > able to open the socket and you will have to restart your OS. And do > not make an error with the string passed . I need to add an exception > for it so it wont crash blender.

July 16, 2014

Re: [Pharo-dev] consideration of Smalltalk "DoIt"

by Esteban A. Maringolo

2014-07-16 11:30 GMT-03:00 Torsten Bergmann <astares(a)gmx.de>: > Hi Esteban, > I think the > > Do/Evaluate it Print it Debug it > menu naming is a tribute to Smalltalk history as it was already part of ST80 > (see http://www.cosc.canterbury.ac.nz/wolfgang.kreutzer/cosc205/images/stShot13.…) > > In this case the text is seen not only as text but as a real expression - maybe > that's the reason for the "it" and also the reason for having this in a separate > menu group divided by a separator line. > > I would not change it, even when it is not consistent or make some people feel > uncomfortable for three reasons: > > 1. The do it/print it/debug it is part of nearly any Smalltalk or Pharo tutorial/books > so this is what people would expect it to look like That's what I'm saying, it's the way it is because of historical reasons. :) However a UI with camel-cased commands (fileOut, printOut), is not a reference of good UI design. > 2. The Cut/Copy/Paste is known from any other UI based operating system and application, > so this is what people would expect it to look like Of course, I wouldn't change it. :) > and the strongest reason: > > 3. If you change "Print it" to just "Print" people would expect something > is coming out of their printer device! ;) I can't see how "Print" means "send to the paper printer" and "Print it" means "convert to a textual representation and print it in the display" ;-) I think the stronger reason is the #1. This is not big deal, let's not make a huge debate (too late) out of this. Ben, say "evaluate" when you want somebody to "DoIt", and I guess that would be fine. Regards!

July 16, 2014

Re: [Pharo-dev] consideration of Smalltalk "DoIt"

by Ben Coman

July 16, 2014

Re: [Pharo-dev] consideration of Smalltalk "DoIt"

by Ron Teitelbaum

Hi All, Smalltalkers do it with style. As a member of the it fan club I would like to send my support for all the its. Could be that I just got used to the syntax but there has never been any doubt as to what the methods do. The purpose of a language is to be clear and useful. I donât find any fault in the clarity, or the ability to learn and remember its. All the best, Ron Teitelbaum From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Santiago Bragagnolo Sent: Wednesday, July 16, 2014 10:24 AM To: Pharo Development List Subject: Re: [Pharo-dev] consideration of Smalltalk "DoIt" I think that the difference is in every language. You do not just debug a c program executing it or compiling it for release, the same with c++ and java or python. I never debugged haskell, but when you execute something in the console you are even implicitly using print-it. instead of do it. Profiling is not different neither, is not that you there is all the time something profiling your applications. I think that real difference is that is not usual to find a language that let you execute what ever you want almost everywhere, because the meaning of what execution is, is slightly different. Then, in other languages it just do not makes sense. You may want to change the menu to be different when you have something selected, i feel it will be more bureau, but it can be cool to try a prototype. 2014-07-15 22:50 GMT+02:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: 2014-07-15 17:30 GMT-03:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2014-07-15 20:27 GMT+02:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > >> I find the "... it" suffix obsolete. "Delete it", "Do it", "Print it", >> etc. >> >> Maybe it made sense in the past, but today it feels weird. >> There is no "Cut it", "Paste it", etc... nor similar in other software. >> IMO, if the menu is contextual, the context already applies the "it" >> (subject). > Did you notice "it" is only mentionned when you will evaluate (do it / print > it / debug it / ... )? > Otherwise, if it's just text editing there is no it. > So there is a sort of logic. IMO that makes sense, because evaluating is a > special action. I did notice. And I believe the "print-it", "do-it" and similar are there because of historical reasons I don't know, but were carried over without questioning it, maybe since ST-80 . :) Why make a distinction between copying text and evaluating/profiling/debugging it? I only saw this in Smalltalk. Esteban A. Maringolo

July 16, 2014

Athens and AntiAliasing

by Thierry Goubier

Hi, I'm trying to see if I can switch on antialiasing when using Athens (for Roassal in particular) but it seems partially implemented? i.e. AthensCairoCanvas>>setAA: is a nop (just comments) even if the Cairo AA constants are initialized. Can I just write the NB cairo_set_alias call myself or is there a reason for having it disabled? Thanks, Thierry

July 16, 2014

Debugger variable display - poor wrapping of collections

by Ben Coman

I have a minor irritation that when displaying a variable in the debugger, collections wrap like this... an OrderedCollection(a MyObject a MyObject a MyObject a.... I'd like to see something like this... an-OrderedCollection( a-MyObject a-MyObject a-MyObject .... Using the dash has the lowest impact code-wise, but maybe the visual-semantics is too great a change? The required code change is shown below in comments... Object>>printOn: aStream | title | title := self class name. aStream nextPutAll: (title first isVowel ifTrue: ['an '] ifFalse: ['a ']); " nextPutAll: (title first isVowel ifTrue: ['an-'] ifFalse: ['a-']); " nextPutAll: title Collection>>printElementsOn: aStream aStream nextPut: $( " ; space " . self do: [:element | aStream print: element] separatedBy: [aStream space]. aStream " space ; " nextPut: $) cheers -ben

July 16, 2014

Re: [Pharo-dev] consideration of Smalltalk "DoIt"

by Torsten Bergmann

Hi Esteban, I think the Do/Evaluate it Print it Debug it menu naming is a tribute to Smalltalk history as it was already part of ST80 (see http://www.cosc.canterbury.ac.nz/wolfgang.kreutzer/cosc205/images/stShot13.…) In this case the text is seen not only as text but as a real expression - maybe that's the reason for the "it" and also the reason for having this in a separate menu group divided by a separator line. I would not change it, even when it is not consistent or make some people feel uncomfortable for three reasons: 1. The do it/print it/debug it is part of nearly any Smalltalk or Pharo tutorial/books so this is what people would expect it to look like 2. The Cut/Copy/Paste is known from any other UI based operating system and application, so this is what people would expect it to look like and the strongest reason: 3. If you change "Print it" to just "Print" people would expect something is coming out of their printer device! ;) We can change anything in Pharo - but not so easy the expectation of users. Bye T. > Gesendet: Mittwoch, 16. Juli 2014 um 16:01 Uhr > Von: "Esteban A. Maringolo" <emaringolo(a)gmail.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] consideration of Smalltalk "DoIt" > > 2014-07-15 23:32 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > On Jul 15, 2014, at 1:50 PM, "Esteban A. Maringolo" <emaringolo(a)gmail.com> wrote: > > >> Why make a distinction between copying text and > >> evaluating/profiling/debugging it? I only saw this in Smalltalk. > > > > ?? I'd be more than annoyed if copying the text "rm -rf *" evaluated it too... > > Well... it would be sending the object at the variable rm the message > selector #- with rf as argument :) > > I'm not sure if I understood what you meant. But I'm talking about > consistency, it is we use "verb + it" for everything, or we don't. > > Ej: > A) > Do/Evaluate it > Print it > Debug it > Copy it > Cut it > Paste it > > B) > Evaluate > Print > Debug > Copy > Cut > Paste > > Certainly the latter feels better to me. And I haven't seen a single > UI/UX guideline suggesting the naming of commands like A. > > But again, maybe i'm lost in translation here. > > Regards. > > Esteban A. Maringolo > >

July 16, 2014

Re: [Pharo-dev] [ANN] Ephestos - Using and Coding Blender from inside Pharo

by Sean P. DeNigris

kilon alios wrote > The goal is to expose Blender coders to the power of Pharo and Pharo to > the > power of Blender Cool! I want this :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/ANN-Ephestos-Using-and-Coding-Blender-from-inside-Pha… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 16, 2014