Re: [Pharo-dev] Improving Pharo By Example
On Wed, Jun 18, 2014 at 6:40 PM, kilon alios kilon.al...@gmail.com wrote: thank you Damien, yes indeed it compiles now. So I was doing it wrong once more :D Sorry for wasting your time, I try to be careful but I make stupid mistakes at times. Will try to be more careful next time. don't problem. I'm not wasting my time because you are doing a job I should have done months ago. So, thank you Kilon! The layout problem still remains though for the Pdf. But I suspect thats a Latex problem. You can see the issue at page 34 of the pdf. I have several images with the layout of the page when it comes to images like sometimes it adds too much whitespace between text and image and now this. Again maybe I am doing something wrong here. could you please tell me exactly where is the problem? What should be different? -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40025 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] Azure Storage Library
Hi there, I'm implementing a library to interact with Azure Storage. I'm already blocked at the first step: generate the authentication header. The header generation is described there: http://msdn.microsoft.com/en-us/library/azure/dd179428.aspx An SDK exists for Ruby: https://github.com/Azure/azure-sdk-for-ruby I've taken the tests from the Ruby SDK to drive my implementation. I have a mismatch that I can't solve with the authentication header. You can run the tests or execute the small scenario from the AZSharedKeyAuth class comment to see where the problem is (i've created a temporary storage account for testing, the account name and key are in the class comment). Apparently something goes wrong in the signature= Base64(HMAC-SHA256(UTF8(StringToSign))). My StringToSign seems to be ok (cr vs lf vs crlf possibly put some mess). My code is there: http://smalltalkhub.com/#!/~francois/AzureStorage Can someone have a look? If you're a company that can send invoices, I don't mind to pay consulting fees if you can help...
[Pharo-dev] [pharo-project/pharo-core] c3f524: 40025
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: c3f5241b513632c7fd5817a03ca759039b887245 https://github.com/pharo-project/pharo-core/commit/c3f5241b513632c7fd5817a03ca759039b887245 Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-06-19 (Thu, 19 Jun 2014) Changed paths: M FuelTests.package/FLMethodContextSerializationTest.class/instance/tests/testMethodContext.st M FuelTests.package/FLMethodContextSerializationTest.class/instance/tests/testMethodContextWithClosureAndSender.st M FuelTests.package/FLMethodContextSerializationTest.class/instance/tests/testMethodContextWithNilPc.st M FuelTests.package/FLMethodContextSerializationTest.class/instance/tests/testMethodContextWithSender.st M FuelTests.package/FLMethodContextSerializationTest.class/instance/tests/testMethodContextWithTemp.st R Morphic-Core.package/Morph.class/instance/change reporting/colorChangedForSubmorph_.st R Morphic-Core.package/Morph.class/instance/recategorized/morphicLayerNumberWithin_.st M Morphic-Core.package/Morph.class/instance/wiw support/addMorphInFrontOfLayer_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script25.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40025.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Zinc-Resource-Meta-Tests.package/ZnMimeTypeTests.class/instance/testing/testLegacy.st Log Message: --- 40025 13341 small simplification: #morphicLayerNumberWithin: https://pharo.fogbugz.com/f/cases/13341 13345 Fix some references to non-existing classes: MethodContext, MIMEType https://pharo.fogbugz.com/f/cases/13345 12859 colorChangedForSubmorph: unused https://pharo.fogbugz.com/f/cases/12859 http://files.pharo.org/image/40/40025.zip
Re: [Pharo-dev] Improving Pharo By Example
did you take a look at the book pdf ? Can you see the page 34 ? by layout I mean the position of the image in the pdf is completely wrong, take a look at the html . Hmtl positions the image correctly , the pdf does not. To be even more specific the image should appear after In order to be able to use SmalltalkHub you will need an account. Using the link provided go to the website with your internet browser. Just click on the Join link and follow the instructions to create a new account. Then login to your account. but it does not, instead it continues the text then it correctly positions the code block MCHttpRepository location: 'http://www.smalltalkhub.com/mc/UserName/ProjectName/main' user: '' password: '' it displays the first line of the code block as the last line of the page , then it goes to the next page and instead of continuing the code block it positions the image then after the image it continues the code block. So basically the image appears inside the code block even though the image and the code block are a few paragraphs apart !!! Now take a look at html it looks perfectly ok as it should be. On Thu, Jun 19, 2014 at 10:59 AM, Damien Cassou damien.cas...@gmail.com wrote: On Wed, Jun 18, 2014 at 6:40 PM, kilon alios kilon.al...@gmail.com wrote: thank you Damien, yes indeed it compiles now. So I was doing it wrong once more :D Sorry for wasting your time, I try to be careful but I make stupid mistakes at times. Will try to be more careful next time. don't problem. I'm not wasting my time because you are doing a job I should have done months ago. So, thank you Kilon! The layout problem still remains though for the Pdf. But I suspect thats a Latex problem. You can see the issue at page 34 of the pdf. I have several images with the layout of the page when it comes to images like sometimes it adds too much whitespace between text and image and now this. Again maybe I am doing something wrong here. could you please tell me exactly where is the problem? What should be different? -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
[Pharo-dev] Pharo logo on files.pharo.org
On the http://files.pharo.org page the picture is missing (it references http://www.pharo-project.org/images/pharo.png) and I think this is gone due to the website redesign. Maybe it can be added again so the page looks complete. Thx T.
Re: [Pharo-dev] Vm on Mac OS 7.5 no cairo
Is anyone else using Pharo on OS X 10.7.5? I run machines on
different OS versions to reduce the risk of catastrophic failures
and to be able to reproduce customer problems.
To be complete:
http://www.mirandabanda.org/files/Cog/VM/VM.r3006/Cog.app-14-24.3006 reports
#('ZipPlugin VMMaker.oscog-eem.655 (i)'
'SocketPlugin VMMaker.oscog-eem.580 (i)'
'UnixOSProcessPlugin VMConstruction-Plugins-OSProcessPlugin.oscog-eem.48 (e)'
'B2DPlugin VMMaker.oscog-eem.702 (i)'
'BitBltPlugin VMMaker.oscog-eem.655 (i)'
'InternetConfigPlugin VMMaker.oscog-eem.580 (i)'
'SecurityPlugin VMMaker.oscog-eem.580 (i)'
'FilePlugin VMMaker.oscog-eem.702 (i)'
'DropPlugin VMMaker.oscog-eem.580 (i)'
'MiscPrimitivePlugin VMMaker.oscog-eem.702 (i)'
'LargeIntegers v1.5 VMMaker.oscog-eem.580 (i)'
'LocalePlugin VMMaker.oscog-eem.580 (i)')
And of course misses the NativeBoost plugin.
Stephan
Re: [Pharo-dev] Pharo logo on files.pharo.org
On 19 Jun 2014, at 10:40, Torsten Bergmann asta...@gmx.de wrote: On the http://files.pharo.org page the picture is missing (it references http://www.pharo-project.org/images/pharo.png) and I think this is gone due to the website redesign. Yes, it should better reference a files in the logo subdirectory… I will fix it. Marcus
Re: [Pharo-dev] Vm on Mac OS 7.5 no cairo
Just to understand a bit more... Mayne I'm wrong, but I think Cairo is
loaded dynamically by the VM, as it is a library used in FFI and it is not
a plugin. So it will appear in that list, just after you use it.
On Thu, Jun 19, 2014 at 10:53 AM, Stephan Eggermont step...@stack.nl
wrote:
Is anyone else using Pharo on OS X 10.7.5? I run machines on
different OS versions to reduce the risk of catastrophic failures
and to be able to reproduce customer problems.
To be complete:
http://www.mirandabanda.org/files/Cog/VM/VM.r3006/Cog.app-14-24.3006
reports
#('ZipPlugin VMMaker.oscog-eem.655 (i)'
'SocketPlugin VMMaker.oscog-eem.580 (i)'
'UnixOSProcessPlugin VMConstruction-Plugins-OSProcessPlugin.oscog-eem.48
(e)'
'B2DPlugin VMMaker.oscog-eem.702 (i)'
'BitBltPlugin VMMaker.oscog-eem.655 (i)'
'InternetConfigPlugin VMMaker.oscog-eem.580 (i)'
'SecurityPlugin VMMaker.oscog-eem.580 (i)'
'FilePlugin VMMaker.oscog-eem.702 (i)'
'DropPlugin VMMaker.oscog-eem.580 (i)'
'MiscPrimitivePlugin VMMaker.oscog-eem.702 (i)'
'LargeIntegers v1.5 VMMaker.oscog-eem.580 (i)'
'LocalePlugin VMMaker.oscog-eem.580 (i)')
And of course misses the NativeBoost plugin.
Stephan
Re: [Pharo-dev] Vm on Mac OS 7.5 no cairo
Bleh, even some plugins are loaded lazily :)
On Thu, Jun 19, 2014 at 11:04 AM, Guillermo Polito
guillermopol...@gmail.com wrote:
Just to understand a bit more... Mayne I'm wrong, but I think Cairo is
loaded dynamically by the VM, as it is a library used in FFI and it is not
a plugin. So it will appear in that list, just after you use it.
On Thu, Jun 19, 2014 at 10:53 AM, Stephan Eggermont step...@stack.nl
wrote:
Is anyone else using Pharo on OS X 10.7.5? I run machines on
different OS versions to reduce the risk of catastrophic failures
and to be able to reproduce customer problems.
To be complete:
http://www.mirandabanda.org/files/Cog/VM/VM.r3006/Cog.app-14-24.3006
reports
#('ZipPlugin VMMaker.oscog-eem.655 (i)'
'SocketPlugin VMMaker.oscog-eem.580 (i)'
'UnixOSProcessPlugin VMConstruction-Plugins-OSProcessPlugin.oscog-eem.48
(e)'
'B2DPlugin VMMaker.oscog-eem.702 (i)'
'BitBltPlugin VMMaker.oscog-eem.655 (i)'
'InternetConfigPlugin VMMaker.oscog-eem.580 (i)'
'SecurityPlugin VMMaker.oscog-eem.580 (i)'
'FilePlugin VMMaker.oscog-eem.702 (i)'
'DropPlugin VMMaker.oscog-eem.580 (i)'
'MiscPrimitivePlugin VMMaker.oscog-eem.702 (i)'
'LargeIntegers v1.5 VMMaker.oscog-eem.580 (i)'
'LocalePlugin VMMaker.oscog-eem.580 (i)')
And of course misses the NativeBoost plugin.
Stephan
Re: [Pharo-dev] Improving Pharo By Example
On Thu, Jun 19, 2014 at 10:24 AM, kilon alios kilon.al...@gmail.com wrote: So basically the image appears inside the code block even though the image and the code block are a few paragraphs apart !!! oh, this! Don't worry about that, LaTeX is doing its job its own way :-). LaTeX try to put the figures at the top of the pages when possible. Best -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
Re: [Pharo-dev] Vm on Mac OS 7.5 no cairo
Guiile wrote: Just to understand a bit more... Mayne I'm wrong, but I think Cairo is loaded dynamically by the VM, as it is a library used in FFI and it is not a plugin. So it will appear in that list, just after you use it. I made the list after I tried using it, and it failed to find cairo. Error: failed to get a symbol address: cairo_image_surface_create And I have 26 dylibs in the plugins directory. If I replace the libcairo.2.dylib by that from the december version, (and force the use of free type fonts...) Roassal2 works (with the text size issues) Stephan
[Pharo-dev] Implementing cull:cull: in symbol
Hi, maybe we should implement #cull:cull: in symbol so that it will call #cull:? Because this looks correct, if block has 1 parameter, then #cull:cull: boils down to #value:, but when we have a symbol instead, we have an exception. I can open an issue and implement that stuff, but I want a feedback from the conceptual point of view. Uko
Re: [Pharo-dev] Implementing cull:cull: in symbol
I believe this was already discussed long ago, with a decision not to go further that #cull: (or #value:) on Symbol, some even find that too much from a design perspective. I like writing code like #(1 2 3) collect: #asString especially interactively, since it is less verbose. In what situation did you encounter a need to add #cull:cull: to Symbol ? On 19 Jun 2014, at 13:42, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, maybe we should implement #cull:cull: in symbol so that it will call #cull:? Because this looks correct, if block has 1 parameter, then #cull:cull: boils down to #value:, but when we have a symbol instead, we have an exception. I can open an issue and implement that stuff, but I want a feedback from the conceptual point of view. Uko
[Pharo-dev] Auto fill free space by widget in Spec
Hi, I’ve implemented a custom model together with adapter. It works fine when I open it alone with Spec, but when I include in in the other model, it appears in a very small size and is not resizing with the window. Am I missing any magic there? Uko
Re: [Pharo-dev] Implementing cull:cull: in symbol
For example in Spec’s ListModel there is a thing called displayBlock:. And I have to write `list displayBlock: [ :package | package name ]`, while I think that `list displayBlock: #name` is clear enough, but the block receives #cull:cull: Uko On 19 Jun 2014, at 13:52, Sven Van Caekenberghe s...@stfx.eu wrote: I believe this was already discussed long ago, with a decision not to go further that #cull: (or #value:) on Symbol, some even find that too much from a design perspective. I like writing code like #(1 2 3) collect: #asString especially interactively, since it is less verbose. In what situation did you encounter a need to add #cull:cull: to Symbol ? On 19 Jun 2014, at 13:42, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, maybe we should implement #cull:cull: in symbol so that it will call #cull:? Because this looks correct, if block has 1 parameter, then #cull:cull: boils down to #value:, but when we have a symbol instead, we have an exception. I can open an issue and implement that stuff, but I want a feedback from the conceptual point of view. Uko
Re: [Pharo-dev] Vm on Mac OS 7.5 no cairo
Then (yes, captain obvious) there is some problem when loading the library :) Now, if you exchange the dylib from cairo and it works, there is a problem in how the library is packaged/compiled. I would not say a VM problem, nor a NativeBoost one. Esteban? :) On Thu, Jun 19, 2014 at 12:49 PM, Stephan Eggermont step...@stack.nl wrote: Guiile wrote: Just to understand a bit more... Mayne I'm wrong, but I think Cairo is loaded dynamically by the VM, as it is a library used in FFI and it is not a plugin. So it will appear in that list, just after you use it. I made the list after I tried using it, and it failed to find cairo. Error: failed to get a symbol address: cairo_image_surface_create And I have 26 dylibs in the plugins directory. If I replace the libcairo.2.dylib by that from the december version, (and force the use of free type fonts...) Roassal2 works (with the text size issues) Stephan
Re: [Pharo-dev] Azure Storage Library
Hi François, You might want to have a look at the code in Zinc-AWS (group AWS in ConfigurationOfZincHTTPComponents), in particular ZnAWSS3Client and ZnAWSS3RequestSignatureTool - it is using similar request signing but does HMAC-SHA1. From a quick glance at the documentation, it seems you have to use Character lf (\r) else you'll get the wrong result. Have you tried signing the examples (canonical strings) in the documentation and comparing with their result ? If you really can't make it work, we can discuss further. Sven On 19 Jun 2014, at 10:05, François Stephany tulipe.mouta...@gmail.com wrote: Hi there, I'm implementing a library to interact with Azure Storage. I'm already blocked at the first step: generate the authentication header. The header generation is described there: http://msdn.microsoft.com/en-us/library/azure/dd179428.aspx An SDK exists for Ruby: https://github.com/Azure/azure-sdk-for-ruby I've taken the tests from the Ruby SDK to drive my implementation. I have a mismatch that I can't solve with the authentication header. You can run the tests or execute the small scenario from the AZSharedKeyAuth class comment to see where the problem is (i've created a temporary storage account for testing, the account name and key are in the class comment). Apparently something goes wrong in the signature= Base64(HMAC-SHA256(UTF8(StringToSign))). My StringToSign seems to be ok (cr vs lf vs crlf possibly put some mess). My code is there: http://smalltalkhub.com/#!/~francois/AzureStorage Can someone have a look? If you're a company that can send invoices, I don't mind to pay consulting fees if you can help...
Re: [Pharo-dev] Implementing cull:cull: in symbol
On 19 Jun 2014, at 1:42 , Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, maybe we should implement #cull:cull: in symbol so that it will call #cull:? Because this looks correct, if block has 1 parameter, then #cull:cull: boils down to #value:, but when we have a symbol instead, we have an exception. I can open an issue and implement that stuff, but I want a feedback from the conceptual point of view. Uko #cull: is supposed to be the equivalent to the #value: protocol, where the parameter is optional. Symbol has no #value:value: message, hence it should have no #cull:cull: either. You could argue it should implement both, with value:value: polymorphic to the block [:a :b | a perform: theSymbol with: b ]. but cull:cull: would then mean equivalence to: for #+ [:a :b | a + b] for #squared [:a | a self] And I don’t see how that’d be intuitive/useful enough to warrant inclusion Considering the sole reason cull: on Symbol exists, is to allow select: etc. to be written using cull so the block arg is optional, but still do aCollection collect: #mySymbol, the closest equivalent would be . aCollection sort: # / aCollection inject: 0 into: #+ which, while might be nice, both have no use for cull:cull: in the same manner: aCollection inject: 0 into: #squared - [:sub :next | sub squared] ??? The whole who is the receiver, what’s going on»-factor of cull:cull: on symbol is non-intuitive enough that at least I feel it’s better to write out the block explicitly. Cheers, Henry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] Implementing cull:cull: in symbol
The thing is that cull:cull: can be used on block with 1 parameter. If you consider symbol as a block with one parameter then it will work in the same style. In other words: methods that use value:value: want to ensure that they are working with 2 param block. Methods that use cull:cull: don’t care what is there, but allow you to customise the result with up to 2 parameters. With symbol you can customise it with 1 parameter. Uko On 19 Jun 2014, at 14:08, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On 19 Jun 2014, at 1:42 , Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, maybe we should implement #cull:cull: in symbol so that it will call #cull:? Because this looks correct, if block has 1 parameter, then #cull:cull: boils down to #value:, but when we have a symbol instead, we have an exception. I can open an issue and implement that stuff, but I want a feedback from the conceptual point of view. Uko #cull: is supposed to be the equivalent to the #value: protocol, where the parameter is optional. Symbol has no #value:value: message, hence it should have no #cull:cull: either. You could argue it should implement both, with value:value: polymorphic to the block [:a :b | a perform: theSymbol with: b ]. but cull:cull: would then mean equivalence to: for #+ [:a :b | a + b] for #squared [:a | a self] And I don’t see how that’d be intuitive/useful enough to warrant inclusion Considering the sole reason cull: on Symbol exists, is to allow select: etc. to be written using cull so the block arg is optional, but still do aCollection collect: #mySymbol, the closest equivalent would be . aCollection sort: # / aCollection inject: 0 into: #+ which, while might be nice, both have no use for cull:cull: in the same manner: aCollection inject: 0 into: #squared - [:sub :next | sub squared] ??? The whole who is the receiver, what’s going on»-factor of cull:cull: on symbol is non-intuitive enough that at least I feel it’s better to write out the block explicitly. Cheers, Henry
Re: [Pharo-dev] Performance for Video Games(Woden Video)
Ronie Salgado wrote I am working on making a video game engine in Pharo Awesome :) - Cheers, Sean -- View this message in context: http://forum.world.st/Performance-for-Video-Games-Woden-Video-tp4762913p4763796.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Vm on Mac OS 7.5 no cairo
On 19 Jun 2014, at 09:03, Guillermo Polito guillermopol...@gmail.com wrote: Then (yes, captain obvious) there is some problem when loading the library :) Now, if you exchange the dylib from cairo and it works, there is a problem in how the library is packaged/compiled. I would not say a VM problem, nor a NativeBoost one. Esteban? :) no idea. as I said before, the tiger demo works for me out of the box (10.9). now I do not have a 10.7 but since nothing of the build process changed (specially the cairo build), I do not understand what can be going bad. Esteban On Thu, Jun 19, 2014 at 12:49 PM, Stephan Eggermont step...@stack.nl wrote: Guiile wrote: Just to understand a bit more... Mayne I'm wrong, but I think Cairo is loaded dynamically by the VM, as it is a library used in FFI and it is not a plugin. So it will appear in that list, just after you use it. I made the list after I tried using it, and it failed to find cairo. Error: failed to get a symbol address: cairo_image_surface_create And I have 26 dylibs in the plugins directory. If I replace the libcairo.2.dylib by that from the december version, (and force the use of free type fonts...) Roassal2 works (with the text size issues) Stephan
Re: [Pharo-dev] Vm on Mac OS 7.5 no cairo
On 19 Jun 2014, at 09:35, Esteban Lorenzano esteba...@gmail.com wrote: On 19 Jun 2014, at 09:03, Guillermo Polito guillermopol...@gmail.com wrote: Then (yes, captain obvious) there is some problem when loading the library :) Now, if you exchange the dylib from cairo and it works, there is a problem in how the library is packaged/compiled. I would not say a VM problem, nor a NativeBoost one. Esteban? :) no idea. as I said before, the tiger demo works for me out of the box (10.9). now I do not have a 10.7 but since nothing of the build process changed (specially the cairo build), I do not understand what can be going bad. what about an “IT Crowd” answer: did you try downloading the vm again? :P Esteban On Thu, Jun 19, 2014 at 12:49 PM, Stephan Eggermont step...@stack.nl wrote: Guiile wrote: Just to understand a bit more... Mayne I'm wrong, but I think Cairo is loaded dynamically by the VM, as it is a library used in FFI and it is not a plugin. So it will appear in that list, just after you use it. I made the list after I tried using it, and it failed to find cairo. Error: failed to get a symbol address: cairo_image_surface_create And I have 26 dylibs in the plugins directory. If I replace the libcairo.2.dylib by that from the december version, (and force the use of free type fonts...) Roassal2 works (with the text size issues) Stephan
Re: [Pharo-dev] Azure Storage Library
Hello Sven, You might want to have a look at the code in Zinc-AWS (group AWS in ConfigurationOfZincHTTPComponents), in particular ZnAWSS3Client and ZnAWSS3RequestSignatureTool - it is using similar request signing but does HMAC-SHA1. Thanks! I wasn't aware of the existence of ZnAWS. Actually, i'm currently using the HMAC-SHA256 implementation of the CloudFork. From a quick glance at the documentation, it seems you have to use Character lf (\r) else you'll get the wrong result. I'm using withUnixLineEndings to ensure the Character lf line ending. You meant \n instead of \r, right? Have you tried signing the examples (canonical strings) in the documentation and comparing with their result ? The problem is that they don't tell with which key they've signed the string. It makes it quite hard to decompose the problem and see where something breaks. The tests in the Ruby SDK are not really useful neither. I'll the other SDKs, maybe the tests are more revealing. If you really can't make it work, we can discuss further. I'll try a bit more and come back if needed! Thanks !
Re: [Pharo-dev] Azure Storage Library
On 19 Jun 2014, at 14:59, François Stephany tulipe.mouta...@gmail.com wrote: Hello Sven, You might want to have a look at the code in Zinc-AWS (group AWS in ConfigurationOfZincHTTPComponents), in particular ZnAWSS3Client and ZnAWSS3RequestSignatureTool - it is using similar request signing but does HMAC-SHA1. Thanks! I wasn't aware of the existence of ZnAWS. Actually, i'm currently using the HMAC-SHA256 implementation of the CloudFork. Is that an all Smalltalk implementation ? Because it would be really good to have SHA256 in the image. From a quick glance at the documentation, it seems you have to use Character lf (\r) else you'll get the wrong result. I'm using withUnixLineEndings to ensure the Character lf line ending. You meant \n instead of \r, right? Yes, of course, sorry. Have you tried signing the examples (canonical strings) in the documentation and comparing with their result ? The problem is that they don't tell with which key they've signed the string. It makes it quite hard to decompose the problem and see where something breaks. How crazy is that ?? (I am trying to be polite here ;-) The tests in the Ruby SDK are not really useful neither. I'll the other SDKs, maybe the tests are more revealing. Good luck. If you really can't make it work, we can discuss further. I'll try a bit more and come back if needed! Thanks !
Re: [Pharo-dev] Improving Pharo By Example
ok I leave it to your capable hands and I will try to position images at the start of the page , though that is easier said than done :D In any case chapters need proof reading so what I commit should never consider the final version. But I always try to produce as much quality as I can. On Thu, Jun 19, 2014 at 12:18 PM, Damien Cassou damien.cas...@gmail.com wrote: On Thu, Jun 19, 2014 at 10:24 AM, kilon alios kilon.al...@gmail.com wrote: So basically the image appears inside the code block even though the image and the code block are a few paragraphs apart !!! oh, this! Don't worry about that, LaTeX is doing its job its own way :-). LaTeX try to put the figures at the top of the pages when possible. Best -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
Re: [Pharo-dev] Implementing cull:cull: in symbol
In other engines where we want scripting to be used, we use a cull: or value: with a prefix. In the case of Spec, this could be specCull:cull:. This could be used as an extension of Symbol without spawning religious wars :). The funny thing is that in all these engines that do define special value: like methods, the implementation looks exactly the same. Perhaps this should tell us that it would be worth having it by default. Doru On Thu, Jun 19, 2014 at 2:16 PM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: The thing is that cull:cull: can be used on block with 1 parameter. If you consider symbol as a block with one parameter then it will work in the same style. In other words: methods that use value:value: want to ensure that they are working with 2 param block. Methods that use cull:cull: don’t care what is there, but allow you to customise the result with up to 2 parameters. With symbol you can customise it with 1 parameter. Uko On 19 Jun 2014, at 14:08, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On 19 Jun 2014, at 1:42 , Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, maybe we should implement #cull:cull: in symbol so that it will call #cull:? Because this looks correct, if block has 1 parameter, then #cull:cull: boils down to #value:, but when we have a symbol instead, we have an exception. I can open an issue and implement that stuff, but I want a feedback from the conceptual point of view. Uko #cull: is supposed to be the equivalent to the #value: protocol, where the parameter is optional. Symbol has no #value:value: message, hence it should have no #cull:cull: either. You could argue it should implement both, with value:value: polymorphic to the block [:a :b | a perform: theSymbol with: b ]. but cull:cull: would then mean equivalence to: for #+ [:a :b | a + b] for #squared [:a | a self] And I don’t see how that’d be intuitive/useful enough to warrant inclusion Considering the sole reason cull: on Symbol exists, is to allow select: etc. to be written using cull so the block arg is optional, but still do aCollection collect: #mySymbol, the closest equivalent would be . aCollection sort: # / aCollection inject: 0 into: #+ which, while might be nice, both have no use for cull:cull: in the same manner: aCollection inject: 0 into: #squared - [:sub :next | sub squared] ??? The whole who is the receiver, what’s going on»-factor of cull:cull: on symbol is non-intuitive enough that at least I feel it’s better to write out the block explicitly. Cheers, Henry -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Improving Pharo By Example
On Thu, Jun 19, 2014 at 3:39 PM, kilon alios kilon.al...@gmail.com wrote: ok I leave it to your capable hands and I will try to position images at the start of the page , though that is easier said than done :D no! Don't do anything like that. LaTeX is capable of doing it by itself. You don't know where the page boundaries will be so it is hopeless for you :-). What you must ensure though, is that all figures are properly referenced in the text. This is a good example: ... bla... bla... see Figure *fig:myfig*. This is a bad example: ... bla... bla... see figure below: This is bad because you can't be sure the figure will be below (it can also be above, LaTeX decides). In any case chapters need proof reading so what I commit should never consider the final version. But I always try to produce as much quality as I can. No problem. -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
Re: [Pharo-dev] Azure Storage Library
You might want to have a look at the code in Zinc-AWS (group AWS in ConfigurationOfZincHTTPComponents), in particular ZnAWSS3Client and ZnAWSS3RequestSignatureTool - it is using similar request signing but does HMAC-SHA1. Thanks! I wasn't aware of the existence of ZnAWS. Actually, i'm currently using the HMAC-SHA256 implementation of the CloudFork. Is that an all Smalltalk implementation ? Because it would be really good to have SHA256 in the image. Yes it is. The class comment says: http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf This class represnets the implementation of CFSHA256 as describied above. Please direct questions or comments about this implementation to Ron Teitelbaum: r...@usmedrec.com This code was extensively coppied from SHA1 by Luciano Notarfrancesco lnotarfrance...@yahoo.com It seems to work for AWS, I wonder what I'm doing wrong here...
[Pharo-dev] [ANN] LaTeX to Pillar converter
I'm happy to announce that I wrote a LaTeX to Pillar converter. This converter should not be considered perfect and proof reading is required. Still, the converter could automatically convert from: https://github.com/SquareBracketAssociates/PharoByExample-english/blob/master/Streams/Streams.tex to: https://github.com/SquareBracketAssociates/UpdatedPharoByExample/blob/master/Streams/Streams.pillar This Pillar file is then exported to either html: https://ci.inria.fr/pharo-contribution/job/UpdatedPharoByExample/lastSuccessfulBuild/artifact/Streams/Streams.pillar.html or pdf: https://ci.inria.fr/pharo-contribution/job/UpdatedPharoByExample/lastSuccessfulBuild/artifact/Streams/Streams.pillar.pdf -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
Re: [Pharo-dev] Azure Storage Library
On 19 Jun 2014, at 15:52, François Stephany tulipe.mouta...@gmail.com wrote: You might want to have a look at the code in Zinc-AWS (group AWS in ConfigurationOfZincHTTPComponents), in particular ZnAWSS3Client and ZnAWSS3RequestSignatureTool - it is using similar request signing but does HMAC-SHA1. Thanks! I wasn't aware of the existence of ZnAWS. Actually, i'm currently using the HMAC-SHA256 implementation of the CloudFork. Is that an all Smalltalk implementation ? Because it would be really good to have SHA256 in the image. Yes it is. The class comment says: http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf This class represnets the implementation of CFSHA256 as describied above. Please direct questions or comments about this implementation to Ron Teitelbaum: r...@usmedrec.com This code was extensively coppied from SHA1 by Luciano Notarfrancesco lnotarfrance...@yahoo.com It seems to work for AWS, I wonder what I'm doing wrong here... You have to be 100% sure that the SHA256, HMAC-SHA256 code works (as opposed to the SHA1, HMAC-SHA1 code) then you absolutely need examples: a known canonical string and keys with a Base64 signature output. Start by making sure you can replicate this in your reference implementation (Ruby, Java, C#) and then start to go to Pharo. Look *very* carefully at each element of the canonical string, one letter difference, one header, punctuation, whitespace, case, date or time format difference will break the whole thing - that is the point of being a signature.
Re: [Pharo-dev] Implementing cull:cull: in symbol
On 19 Jun 2014, at 15:47, Tudor Girba tu...@tudorgirba.com wrote: In other engines where we want scripting to be used, we use a cull: or value: with a prefix. In the case of Spec, this could be specCull:cull:. This could be used as an extension of Symbol without spawning religious wars :). Yes, also I can use a block with 1 param. The thing is that as far as I understand cull:cull: means: if possible: “value:value:” else if possible: “value:” else “value” So this can work for block. But maybe cull: has different philosophy Uko The funny thing is that in all these engines that do define special value: like methods, the implementation looks exactly the same. Perhaps this should tell us that it would be worth having it by default. Doru On Thu, Jun 19, 2014 at 2:16 PM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: The thing is that cull:cull: can be used on block with 1 parameter. If you consider symbol as a block with one parameter then it will work in the same style. In other words: methods that use value:value: want to ensure that they are working with 2 param block. Methods that use cull:cull: don’t care what is there, but allow you to customise the result with up to 2 parameters. With symbol you can customise it with 1 parameter. Uko On 19 Jun 2014, at 14:08, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On 19 Jun 2014, at 1:42 , Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, maybe we should implement #cull:cull: in symbol so that it will call #cull:? Because this looks correct, if block has 1 parameter, then #cull:cull: boils down to #value:, but when we have a symbol instead, we have an exception. I can open an issue and implement that stuff, but I want a feedback from the conceptual point of view. Uko #cull: is supposed to be the equivalent to the #value: protocol, where the parameter is optional. Symbol has no #value:value: message, hence it should have no #cull:cull: either. You could argue it should implement both, with value:value: polymorphic to the block [:a :b | a perform: theSymbol with: b ]. but cull:cull: would then mean equivalence to: for #+ [:a :b | a + b] for #squared [:a | a self] And I don’t see how that’d be intuitive/useful enough to warrant inclusion Considering the sole reason cull: on Symbol exists, is to allow select: etc. to be written using cull so the block arg is optional, but still do aCollection collect: #mySymbol, the closest equivalent would be . aCollection sort: # / aCollection inject: 0 into: #+ which, while might be nice, both have no use for cull:cull: in the same manner: aCollection inject: 0 into: #squared - [:sub :next | sub squared] ??? The whole who is the receiver, what’s going on»-factor of cull:cull: on symbol is non-intuitive enough that at least I feel it’s better to write out the block explicitly. Cheers, Henry -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Implementing cull:cull: in symbol
Can somebody please tell me the semantic difference between #cull: and #value: ? 'Cull' is not a word I ever used in any english based conversation :) Regards, -- Esteban. ps: I'm a big fan of having a valuable protocol, implemented by both Symbol and BlockClosure (and MessageSend), and I miss this behavior in Pharo. Esteban A. Maringolo 2014-06-19 11:14 GMT-03:00 Yuriy Tymchuk yuriy.tymc...@me.com: On 19 Jun 2014, at 15:47, Tudor Girba tu...@tudorgirba.com wrote: In other engines where we want scripting to be used, we use a cull: or value: with a prefix. In the case of Spec, this could be specCull:cull:. This could be used as an extension of Symbol without spawning religious wars :). Yes, also I can use a block with 1 param. The thing is that as far as I understand cull:cull: means: if possible: “value:value:” else if possible: “value:” else “value” So this can work for block. But maybe cull: has different philosophy Uko The funny thing is that in all these engines that do define special value: like methods, the implementation looks exactly the same. Perhaps this should tell us that it would be worth having it by default. Doru On Thu, Jun 19, 2014 at 2:16 PM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: The thing is that cull:cull: can be used on block with 1 parameter. If you consider symbol as a block with one parameter then it will work in the same style. In other words: methods that use value:value: want to ensure that they are working with 2 param block. Methods that use cull:cull: don’t care what is there, but allow you to customise the result with up to 2 parameters. With symbol you can customise it with 1 parameter. Uko On 19 Jun 2014, at 14:08, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On 19 Jun 2014, at 1:42 , Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, maybe we should implement #cull:cull: in symbol so that it will call #cull:? Because this looks correct, if block has 1 parameter, then #cull:cull: boils down to #value:, but when we have a symbol instead, we have an exception. I can open an issue and implement that stuff, but I want a feedback from the conceptual point of view. Uko #cull: is supposed to be the equivalent to the #value: protocol, where the parameter is optional. Symbol has no #value:value: message, hence it should have no #cull:cull: either. You could argue it should implement both, with value:value: polymorphic to the block [:a :b | a perform: theSymbol with: b ]. but cull:cull: would then mean equivalence to: for #+ [:a :b | a + b] for #squared [:a | a self] And I don’t see how that’d be intuitive/useful enough to warrant inclusion Considering the sole reason cull: on Symbol exists, is to allow select: etc. to be written using cull so the block arg is optional, but still do aCollection collect: #mySymbol, the closest equivalent would be . aCollection sort: # / aCollection inject: 0 into: #+ which, while might be nice, both have no use for cull:cull: in the same manner: aCollection inject: 0 into: #squared - [:sub :next | sub squared] ??? The whole who is the receiver, what’s going on»-factor of cull:cull: on symbol is non-intuitive enough that at least I feel it’s better to write out the block explicitly. Cheers, Henry -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Implementing cull:cull: in symbol
http://www.wordreference.com/es/translation.asp?tranword=cull yet, it does not looks like having anything to do with executing a block with optional parameters :) On 19 Jun 2014, at 11:24, Esteban A. Maringolo emaring...@gmail.com wrote: Can somebody please tell me the semantic difference between #cull: and #value: ? 'Cull' is not a word I ever used in any english based conversation :) Regards, -- Esteban. ps: I'm a big fan of having a valuable protocol, implemented by both Symbol and BlockClosure (and MessageSend), and I miss this behavior in Pharo. Esteban A. Maringolo 2014-06-19 11:14 GMT-03:00 Yuriy Tymchuk yuriy.tymc...@me.com: On 19 Jun 2014, at 15:47, Tudor Girba tu...@tudorgirba.com wrote: In other engines where we want scripting to be used, we use a cull: or value: with a prefix. In the case of Spec, this could be specCull:cull:. This could be used as an extension of Symbol without spawning religious wars :). Yes, also I can use a block with 1 param. The thing is that as far as I understand cull:cull: means: if possible: “value:value:” else if possible: “value:” else “value” So this can work for block. But maybe cull: has different philosophy Uko The funny thing is that in all these engines that do define special value: like methods, the implementation looks exactly the same. Perhaps this should tell us that it would be worth having it by default. Doru On Thu, Jun 19, 2014 at 2:16 PM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: The thing is that cull:cull: can be used on block with 1 parameter. If you consider symbol as a block with one parameter then it will work in the same style. In other words: methods that use value:value: want to ensure that they are working with 2 param block. Methods that use cull:cull: don’t care what is there, but allow you to customise the result with up to 2 parameters. With symbol you can customise it with 1 parameter. Uko On 19 Jun 2014, at 14:08, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On 19 Jun 2014, at 1:42 , Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, maybe we should implement #cull:cull: in symbol so that it will call #cull:? Because this looks correct, if block has 1 parameter, then #cull:cull: boils down to #value:, but when we have a symbol instead, we have an exception. I can open an issue and implement that stuff, but I want a feedback from the conceptual point of view. Uko #cull: is supposed to be the equivalent to the #value: protocol, where the parameter is optional. Symbol has no #value:value: message, hence it should have no #cull:cull: either. You could argue it should implement both, with value:value: polymorphic to the block [:a :b | a perform: theSymbol with: b ]. but cull:cull: would then mean equivalence to: for #+ [:a :b | a + b] for #squared [:a | a self] And I don’t see how that’d be intuitive/useful enough to warrant inclusion Considering the sole reason cull: on Symbol exists, is to allow select: etc. to be written using cull so the block arg is optional, but still do aCollection collect: #mySymbol, the closest equivalent would be . aCollection sort: # / aCollection inject: 0 into: #+ which, while might be nice, both have no use for cull:cull: in the same manner: aCollection inject: 0 into: #squared - [:sub :next | sub squared] ??? The whole who is the receiver, what’s going on»-factor of cull:cull: on symbol is non-intuitive enough that at least I feel it’s better to write out the block explicitly. Cheers, Henry -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Vm on Mac OS 7.5 no cairo
Esteban wrote: no idea. as I said before, the tiger demo works for me out of the box (10.9). now I do not have a 10.7 but since nothing of the build process changed (specially the cairo build), I do not understand what can be going bad Does anyone have a 10.7.5 there to see if it is a problem with my machine only? Or was the build box upgraded? 'newer libc style problem?' what about an “IT Crowd” answer: did you try downloading the vm again? :P Tried again with the latest 352. Same problem. Stephan
Re: [Pharo-dev] Vm on Mac OS 7.5 no cairo
On 19 Jun 2014, at 11:33, Stephan Eggermont step...@stack.nl wrote: Esteban wrote: no idea. as I said before, the tiger demo works for me out of the box (10.9). now I do not have a 10.7 but since nothing of the build process changed (specially the cairo build), I do not understand what can be going bad Does anyone have a 10.7.5 there to see if it is a problem with my machine only? Or was the build box upgraded? 'newer libc style problem?’ it was updated like a lot of time ago (more than 6 months). It shouldn’t be a problem if older version worked… but who knows :S what about an “IT Crowd” answer: did you try downloading the vm again? :P Tried again with the latest 352. Same problem. but then is a problem in the build of cairo library… and yes, probably a problem of SDK versions. I do not have the time to check now (also, I’m supposed to be on holidays… the weirdest holidays ever… but holidays after all :P). I will check it as soon as I’m close to the infrastructure. Esteban Stephan
Re: [Pharo-dev] Where is the postcard with syntax?
Simple ~= Easy. Smalltalk is simple (simpler then most of other PLs), but it's not easy (to understand and master, especially after other PLs). -- Best regards, Dennis Schetinin 2014-06-17 11:59 GMT+04:00 kilon alios kilon.al...@gmail.com: personally I don't like this postcard , it looks too much like snake oil marketing to me. It creates the illusion that Pharo is much simpler than other programming languages as a programming language while nothing can be further from the truth. The idea here is to prove to the viewer that Pharo is based on a very simple recipe and that is of course true. But if we have to be honest is should come with a disclaimer for the potential users that Pharo is no blue pill and there tons of things outside this postcard you need to learn if you want to create the simplest Pharo application. I will be frank , as a language I dont find Pharo any simpler than let's say python , which I am more familiar with. And the fact that there is this simple recipe gave me zero benefits to me so far. Its a cool trick that may come handy down the line if I want to shape the language more to my needs, but I dont see doing this to a day by day basis. Now a living coding postcard stating the workflow of Pharo and demonstrating the power of the debugger is much more honest and frankly better marketing for Pharo. You show something to a person that will benefit his workflow on a day by day basis. On Tue, Jun 17, 2014 at 10:32 AM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Now, who is creative enough to add “dynamic array” (one with curly braces) and temporaries in a block to the original thing: exampleWithNumber: x | y | true false not (nil isNil) ifFalse: [self halt]. y := self size + super size. #($a #a a 1 1.0) do: [ :each | Transcript show: (each class name); show: ' ']. ^x y Uko On 16 Jun 2014, at 15:35, Oscar Nierstrasz oscar.nierstr...@gmail.com wrote: I got it from Stef, who always said it came originally from Ralph Johnson. http://c2.com/cgi-bin/wiki?SmalltalkSyntaxInaPostcard Googling around finds various copies of this, but no original source. Oscar On 16 Jun 2014, at 10:58 , Yuriy Tymchuk yuriy.tymc...@me.com wrote: I guess it’s here: http://files.pharo.org/media/flyer-cheat-sheet.pdf I think that it would be interesting to put the syntax on a postcard. It can work as a proof of concept, some addition cheat-sheet for newcomers and also as some king of souvenir. Uko On 16 Jun 2014, at 10:36, stepharo steph...@free.fr wrote: you have the flyer of Damien (no idea where it is) but no real postcard. Stef On 16/6/14 09:35, Yuriy Tymchuk wrote: Hi guys, we all are talking about the syntax fitting in a postcard, but was there any real postcard with Pharo syntax prototype? This would be really interesting. Uko
Re: [Pharo-dev] Azure Storage Library
Got it. It's super stupid. The key they give to feed the HMAC-SHA256 is actually a base64 string that needs to be decoded. It's not mentionned in the docs and I missed the constructor of the Signer in Ruby: # Public: Initialize the Signer. # # access_key - The access_key encoded in Base64. Defaults to the one # in the global configuration. def initialize(access_key=Azure.config.storage_access_key) @access_key = Base64.strict_decode64(access_key) end Tests are passing now :) Thanks for your patience Sven! On Thu, Jun 19, 2014 at 4:01 PM, Sven Van Caekenberghe s...@stfx.eu wrote: On 19 Jun 2014, at 15:52, François Stephany tulipe.mouta...@gmail.com wrote: You might want to have a look at the code in Zinc-AWS (group AWS in ConfigurationOfZincHTTPComponents), in particular ZnAWSS3Client and ZnAWSS3RequestSignatureTool - it is using similar request signing but does HMAC-SHA1. Thanks! I wasn't aware of the existence of ZnAWS. Actually, i'm currently using the HMAC-SHA256 implementation of the CloudFork. Is that an all Smalltalk implementation ? Because it would be really good to have SHA256 in the image. Yes it is. The class comment says: http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf This class represnets the implementation of CFSHA256 as describied above. Please direct questions or comments about this implementation to Ron Teitelbaum: r...@usmedrec.com This code was extensively coppied from SHA1 by Luciano Notarfrancesco lnotarfrance...@yahoo.com It seems to work for AWS, I wonder what I'm doing wrong here... You have to be 100% sure that the SHA256, HMAC-SHA256 code works (as opposed to the SHA1, HMAC-SHA1 code) then you absolutely need examples: a known canonical string and keys with a Base64 signature output. Start by making sure you can replicate this in your reference implementation (Ruby, Java, C#) and then start to go to Pharo. Look *very* carefully at each element of the canonical string, one letter difference, one header, punctuation, whitespace, case, date or time format difference will break the whole thing - that is the point of being a signature.
Re: [Pharo-dev] vm over android
Can you share what is the intended use of the android vm that you're building? -_^ ? Run StackVM on an android is not enough from intellectual point of view ? I am not sure to understand the question. Why I do that, Because I can :-) I am based on the StackVM unix, my main objective is to change less sources as possible to keep that easy to maintain. I used a fork of PharoVM because the process is simpler for merging and reviewing my changes. And because I using the Pharo-contribution (jenkins) infrastructure to generate VM as I do for RaspberryPi. The first objective is to have something usable on Android, which can be easily update if for whatever reason I decide to stop or if someone want to do it own android App. First step: -Having that running, with graphic based on unix source (with some change but less possible). Next step: - have fun with it and wrap it with a nice android app. - a lot of cool idea that people can do because everything will be public. If it isn't precise enough, be more direct :-). On 18 Jun 2014, at 18:44, Hilaire Fernandes hilaire.fernan...@gmail.com wrote: Hi Jean-Baptiste, Dmitry wrote some hook to call the Android Virtual keyboard from the image, and may be some other I forget about. I get the source of CogDroid from him. :-) Most of the java code and the hook that he did is conserved they are extract from the platform android source. And I create a External plugin display for android. Hilaire Le 18/06/2014 14:56, Jean Baptiste Arnaud a écrit : CogDroid, project is not maintain since 3 or 4 years. But still seems work (just have a completely separated source). Peoples give me all the key to revive it. I take the source of Cogdroid for understand what they do and redo it changing less thing possible in unix source. -- Dr. Geo http://drgeo.eu iStoa - https://launchpad.net/istoa Best Regards Dr Arnaud jbaptiste.arn...@gmail.com
Re: [Pharo-dev] Implementing cull:cull: in symbol
A stretch for rational behind cull: We are 'culling' the excess variables passed to the block (roughly equivalent to killing animals when there are too many of them). On Thu, Jun 19, 2014 at 7:31 AM, Esteban Lorenzano esteba...@gmail.com wrote: http://www.wordreference.com/es/translation.asp?tranword=cull yet, it does not looks like having anything to do with executing a block with optional parameters :) On 19 Jun 2014, at 11:24, Esteban A. Maringolo emaring...@gmail.com wrote: Can somebody please tell me the semantic difference between #cull: and #value: ? 'Cull' is not a word I ever used in any english based conversation :) Regards, -- Esteban. ps: I'm a big fan of having a valuable protocol, implemented by both Symbol and BlockClosure (and MessageSend), and I miss this behavior in Pharo. Esteban A. Maringolo 2014-06-19 11:14 GMT-03:00 Yuriy Tymchuk yuriy.tymc...@me.com: On 19 Jun 2014, at 15:47, Tudor Girba tu...@tudorgirba.com wrote: In other engines where we want scripting to be used, we use a cull: or value: with a prefix. In the case of Spec, this could be specCull:cull:. This could be used as an extension of Symbol without spawning religious wars :). Yes, also I can use a block with 1 param. The thing is that as far as I understand cull:cull: means: if possible: “value:value:” else if possible: “value:” else “value” So this can work for block. But maybe cull: has different philosophy Uko The funny thing is that in all these engines that do define special value: like methods, the implementation looks exactly the same. Perhaps this should tell us that it would be worth having it by default. Doru On Thu, Jun 19, 2014 at 2:16 PM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: The thing is that cull:cull: can be used on block with 1 parameter. If you consider symbol as a block with one parameter then it will work in the same style. In other words: methods that use value:value: want to ensure that they are working with 2 param block. Methods that use cull:cull: don’t care what is there, but allow you to customise the result with up to 2 parameters. With symbol you can customise it with 1 parameter. Uko On 19 Jun 2014, at 14:08, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On 19 Jun 2014, at 1:42 , Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, maybe we should implement #cull:cull: in symbol so that it will call #cull:? Because this looks correct, if block has 1 parameter, then #cull:cull: boils down to #value:, but when we have a symbol instead, we have an exception. I can open an issue and implement that stuff, but I want a feedback from the conceptual point of view. Uko #cull: is supposed to be the equivalent to the #value: protocol, where the parameter is optional. Symbol has no #value:value: message, hence it should have no #cull:cull: either. You could argue it should implement both, with value:value: polymorphic to the block [:a :b | a perform: theSymbol with: b ]. but cull:cull: would then mean equivalence to: for #+ [:a :b | a + b] for #squared [:a | a self] And I don’t see how that’d be intuitive/useful enough to warrant inclusion Considering the sole reason cull: on Symbol exists, is to allow select: etc. to be written using cull so the block arg is optional, but still do aCollection collect: #mySymbol, the closest equivalent would be . aCollection sort: # / aCollection inject: 0 into: #+ which, while might be nice, both have no use for cull:cull: in the same manner: aCollection inject: 0 into: #squared - [:sub :next | sub squared] ??? The whole who is the receiver, what’s going on»-factor of cull:cull: on symbol is non-intuitive enough that at least I feel it’s better to write out the block explicitly. Cheers, Henry -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Vm on Mac OS 7.5 no cairo
Esteban wrote: I do not have the time to check now (also, I’m supposed to be on holidays… the weirdest holidays ever… but holidays after all :P). I will check it as soon as I’m close to the infrastructure. Thank you, that would be appreciated. Stephan
Re: [Pharo-dev] vm over android
2014-06-18 15:39 GMT+02:00 Esteban A. Maringolo emaring...@gmail.com: Jean, Can you share what is the intended use of the android vm that you're building? - Deploying application on Android - Proving to big customers Pharo can run on ARM processor on the contrary to several other smalltalks No ? Regards! Esteban A. Maringolo 2014-06-18 9:56 GMT-03:00 Jean Baptiste Arnaud jbaptiste.arn...@gmail.com : I am really close to finish the android VM, only based on the Unix source (just decorate with less than 20 lines of codes, I need a entry point for the interpreter loop and some convention that cannot change via the android builder). + one graphical plugin and a C file for communicate between C and Java. CogDroid, project is not maintain since 3 or 4 years. But still seems work (just have a completely separated source). Peoples give me all the key to revive it. I take the source of Cogdroid for understand what they do and redo it changing less thing possible in unix source. My VM run without the graphics and with a subset of plugin (file, socket and some of them I cannot remember). Road map: - Full compiling and packaging process: Done. - Fix interpreter headless: Done. - be able to generate and load external lib on the fly from android: done - Graphical plugin: In progress. - reintroduce slowly and fix all the removed plugins: todo. - Nice android connectivity: todo. (all event manage, list of image, blablabla) - Create a CMakeGenerator extension to have a really nice way to generate project. Once a graphical version come out I promise some picture and a website. But again I do that on my free time :-).
Re: [Pharo-dev] Auto fill free space by widget in Spec
Thanks Ben! On 19 Jun 2014, at 13:59, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: In your morphic adapter, you probably missed hResizing: #spaceFill; vResizing: #spaceFill; Ben On 19 Jun 2014, at 13:56, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, I’ve implemented a custom model together with adapter. It works fine when I open it alone with Spec, but when I include in in the other model, it appears in a very small size and is not resizing with the window. Am I missing any magic there? Uko
Re: [Pharo-dev] [Moose-dev] CodeCity and Spec
Yay, I’ve done that! CodeCity and Spec: http://quick.as/blq9f5d1 On 17 Jun 2014, at 11:27, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: From what I remember, it was something like: RoassalModel new script: [ :view :canvas | my roassal stuff ]; openWithSpec Or you can then embed it as any other spec model Ben On 17 Jun 2014, at 10:27, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Are there any examples how to use it? I’m not a Spec guru, so any snipers are useful :) Uko On 13 Jun 2014, at 14:34, Johan Fabry jfa...@dcc.uchile.cl wrote: Hola, AFAIK there are no plans for that. Maybe there is an alternative: there is a Roassal2 adaptor for Spec, Roassal2Spec package, which should now come with Roassal2. It allows you to have any Roassal2 visualization as a Spec ComposableModel. On Jun 13, 2014, at 4:47 AM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi all, are there any suggestions for integrating CodeCity into Spec? E.g. using CodeCity visualisation in a view build by Spec. Uko ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev --- Save our in-boxes! http://emailcharter.org --- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] vm over android
2014-06-19 12:35 GMT-03:00 Jean Baptiste Arnaud jbaptiste.arn...@gmail.com: Can you share what is the intended use of the android vm that you're building? -_^ ? Run StackVM on an android is not enough from intellectual point of view ? I am not sure to understand the question. Why I do that, Because I can :-) It's a fair answer. :) The first objective is to have something usable on Android, which can be easily update if for whatever reason I decide to stop or if someone want to do it own android App. First step: -Having that running, with graphic based on unix source (with some change but less possible). I like the idea of being able to instantiate a VM (SqueakVM.java) inside an Android bound Service, and forward good part of the logic to Smalltalk. But I don't know if the VM can run headless (without a SqueakView), or accept evals other than from a socket connection. I didn't see any evaluate(String code) method in SqueakVM.java when I analyzed the CogDroid vm back then. If it isn't precise enough, be more direct :-). You kind of already answered my question, but I was wondering if there was an existing user of this new VM, for a specific application or game. And also if this VM was meant just to run on Android or also integrate with it. Regards! Esteban A. Maringolo
[Pharo-dev] Cloudfork HMAC-SHA256 in System-Hashing
Does it make sense from a license point of view and practical point of view to include the CloudFork HMAC-SHA256 implementation (CFSH256 class) in the System-Hashing package (in where there's already SHA1 and MD5) ?
Re: [Pharo-dev] Cloudfork HMAC-SHA256 in System-Hashing
On 19.06.2014, at 17:59, François Stephany tulipe.mouta...@gmail.com wrote: Does it make sense from a license point of view and practical point of view to include the CloudFork HMAC-SHA256 implementation (CFSH256 class) in the System-Hashing package (in where there's already SHA1 and MD5) ? Can Cloudfork HMAC-SHA256 be easily parameterized with, say, an SHA256 base implementation? Or does it require extra stuff? In the former case I probably wouldn’t add it. In the latter case it’s open for discussion. Personally, I think it belongs into a separate package, not into System-Hashing. Cheers, Max
Re: [Pharo-dev] Cloudfork HMAC-SHA256 in System-Hashing
I want to have a look, if you tell me where to look... On 19 Jun 2014, at 18:03, Max Leske maxle...@gmail.com wrote: On 19.06.2014, at 17:59, François Stephany tulipe.mouta...@gmail.com wrote: Does it make sense from a license point of view and practical point of view to include the CloudFork HMAC-SHA256 implementation (CFSH256 class) in the System-Hashing package (in where there's already SHA1 and MD5) ? Can Cloudfork HMAC-SHA256 be easily parameterized with, say, an SHA256 base implementation? Or does it require extra stuff? In the former case I probably wouldn’t add it. In the latter case it’s open for discussion. Personally, I think it belongs into a separate package, not into System-Hashing. Cheers, Max
[Pharo-dev] Pharo VM crash on seom DrGeo sketch
Hi, I have some VM crash on some DrGeo. It happens from the DrGeo file dialog when the preview of a sketch is computed. It is repeatable. I saw it on Mac, then in Linux as well. See below the log Hilaire -- Dr. Geo http://drgeo.eu iStoa - https://launchpad.net/istoa hilaire@pchome ~/Travaux/Developpement/DrGeoII/trunk/build/tmp/DrGeo.app $ ./DrGeo.sh last object overwritten /home/hilaire/Travaux/Developpement/DrGeoII/trunk/build/tmp/DrGeo.app/Contents/Linux/pharo pharo VM version: 3.9-7 #1 Sat Jun 14 17:26:13 CEST 2014 gcc 4.6.3 [Production ITHB VM] Built from: NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.20 uuid: cf2a-897d-48fd-8251-6789dd21d958 Jun 14 2014 With: NBCogit NativeBoost-CogPlugin-EstebanLorenzano.20 uuid: cf2a-897d-48fd-8251-6789dd21d958 Jun 14 2014 Revision: https://github.com/pharo-project/pharo-vm.git Commit: 0e8bbfbaeb03237fa6bb63ba834773fab18ca307 Date: 2014-06-14 12:20:21 -0300 By: Esteban Lorenzano esteba...@gmail.com Jenkins build #14833 Build host: Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux plugin path: /home/hilaire/Travaux/Developpement/DrGeoII/trunk/build/tmp/DrGeo.app/Contents/Linux [default: /home/hilaire/Travaux/Developpement/DrGeoII/trunk/build/tmp/DrGeo.app/Contents/Linux/] C stack backtrace registers: */home/hilaire/Travaux/Developpement/DrGeoII/trunk/build/tmp/DrGeo.app/Contents/Linux/pharo[0x809fc8c] /home/hilaire/Travaux/Developpement/DrGeoII/trunk/build/tmp/DrGeo.app/Contents/Linux/pharo(error+0x17)[0x809fe97] /home/hilaire/Travaux/Developpement/DrGeoII/trunk/build/tmp/DrGeo.app/Contents/Linux/pharo[0x8074a98] /home/hilaire/Travaux/Developpement/DrGeoII/trunk/build/tmp/DrGeo.app/Contents/Linux/pharo[0x8074bf0/home/hilaire/Travaux/Developpement/DrGeoII/trunk/build/tmp/DrGeo.app/Contents/Linux/pharo(createClosureNumArgsnumCopiedstartpc+0x109)[0x807a6d9] /home/hilaire/Travaux/Developpement/DrGeoII/trunk/build/tmp/DrGeo.app/Contents/Linux/pharo[0x806746f] [0x7755a5a3] [0x7762b20c] [0x7762b20c] [0x7762b20c] [0x7755a648] [0x77590bd3] Smalltalk stack dump: 0xbfb0cab0 M MethodContext(ContextPart)copyTo:blocks: 0x78f0c128: a(n) MethodContext 0xbfb0cad8 M MethodContext(ContextPart)copyTo:blocks: 0x78f0c000: a(n) MethodContext 0xbfb0cb00 M MethodContext(ContextPart)copyTo:blocks: 0x78f0b854: a(n) MethodContext 0xbfb0cb28 M MethodContext(ContextPart)copyTo:blocks: 0x78f0b7f8: a(n) MethodContext 0xbfb0b9b4 M MethodContext(ContextPart)copyTo:blocks: 0x78f0b79c: a(n) MethodContext 0xbfb0b9dc M MethodContext(ContextPart)copyTo:blocks: 0x78f0b740: a(n) MethodContext 0xbfb0ba0c I MethodContext(ContextPart)copyTo:blocks: 0x78f0b5c0: a(n) MethodContext 0xbfb0ba34 I MethodContext(ContextPart)copyTo: 0x78f0b5c0: a(n) MethodContext 0xbfb0ba58 I SubscriptOutOfBounds(Exception)freezeUpTo: 0x78f0b598: a(n) SubscriptOutOfBounds 0xbfb0ba7c I SubscriptOutOfBounds(Exception)freeze 0x78f0b598: a(n) SubscriptOutOfBounds 0xbfb0baa0 M [] in DrGSegmentMarkMorph(Morph)fullDrawOn: 0x78dbf78c: a(n) DrGSegmentMarkMorph 0xbfb0babc M BlockClosurecull: 0x78f0af1c: a(n) BlockClosure 0xbfb0bae4 I [] in MethodContext(ContextPart)handleSignal: 0x78f0b8b0: a(n) MethodContext 0xbfb0bb04 M BlockClosureensure: 0x78f0b9c4: a(n) BlockClosure 0xbfb0bb2c I MethodContext(ContextPart)handleSignal: 0x78f0b8b0: a(n) MethodContext 0xbfb059d0 I SubscriptOutOfBounds(Exception)signal 0x78f0b598: a(n) SubscriptOutOfBounds 0xbfb059f0 I SubscriptOutOfBounds classsignalFor:lowerBound:upperBound:in: 0x778bb480: a(n) SubscriptOutOfBounds class 0xbfb05a20 I SubscriptOutOfBounds classsignalFor:lowerBound:upperBound: 0x778bb480: a(n) SubscriptOutOfBounds class 0xbfb05a4c I SubscriptOutOfBounds classsignalFor: 0x778bb480: a(n) SubscriptOutOfBounds class 0xbfb05a70 I Array(Object)errorSubscriptBounds: 0x782de944: a(n) Array 0xbfb05a8c M Array(Object)at: 0x782de944: a(n) Array 0xbfb05aa8 M Array(SequenceableCollection)third 0x782de944: a(n) Array 0xbfb05b04 I [] in DrGSegmentMarkMorph(PolygonMorph)drawDashedBorderOn:usingEnds: 0x78dbf78c: a(n) DrGSegmentMarkMorph 0xbfb05b2c M [] in DrGSegmentMarkMorph(PolygonMorph)lineSegmentsDo: 0x78dbf78c: a(n) DrGSegmentMarkMorph 0xbfb099d0 M Array(SequenceableCollection)do: 0x78e174b4: a(n) Array 0xbfb099f4 M DrGSegmentMarkMorph(PolygonMorph)lineSegmentsDo: 0x78dbf78c: a(n) DrGSegmentMarkMorph 0xbfb09a2c I DrGSegmentMarkMorph(PolygonMorph)drawDashedBorderOn:usingEnds: 0x78dbf78c: a(n) DrGSegmentMarkMorph 0xbfb09a54 M DrGSegmentMarkMorph(PolygonMorph)drawBorderOn:usingEnds: 0x78dbf78c: a(n) DrGSegmentMarkMorph 0xbfb09a78 M DrGSegmentMarkMorph(DrGPolylineMorph)drawOn: 0x78dbf78c: a(n) DrGSegmentMarkMorph 0xbfb09a94 M DrGSegmentMarkMorphdrawOn: 0x78dbf78c: a(n) DrGSegmentMarkMorph 0xbfb09ab0 M FormCanvas(Canvas)draw: 0x78eec2c4: a(n) FormCanvas 0xbfb09acc M FormCanvas(Canvas)drawMorph: 0x78eec2c4: a(n) FormCanvas 0xbfb09aec M [] in DrGSegmentMarkMorph(Morph)fullDrawOn: 0x78dbf78c: a(n) DrGSegmentMarkMorph
Re: [Pharo-dev] vm over android
Hi Clement, 2014-06-19 12:52 GMT-03:00 Clément Bera bera.clem...@gmail.com: 2014-06-18 15:39 GMT+02:00 Esteban A. Maringolo emaring...@gmail.com: Can you share what is the intended use of the android vm that you're building? - Deploying application on Android - Proving to big customers Pharo can run on ARM processor on the contrary to several other smalltalks What kind of applications? Is there an business interest of running on ARM processors? Is there a sale advantage of having this? I don't want to sound too inquisitive nor pedantic, those are real questions. As stated in previous mails, running on the platform is a technical challenge per se (I couldn't make it if I wanted), but it's just a very small part of deploying to Android. And I'm not talking about app stores. Even though Android (AOSP) is Linux based, the memory/battery constraints makes that apps or services lifecycle completely different to regular unix processes. And I don't see how this fits into the whole android environment. Last time I tried (+1yr) it the VM was a permanent process, without access to device sensors, etc.[*] I have a genuine interest in this topic, because my company depends both on Pharo and Android (native) software. But how I see this, the advantage of Pharo running on Android for devices other than phones/tablets, more kind of internet of things devices. The advantage is also that the image is an asset of the vm, so you can update your app without having to reinstall it through the platform app management. Please don't let this stop you guys from doing this VM even for the fun/sake of doing it. But as you are making this public, I feel allowed to ask questions and add comments. You can simply ignore them. :) Regards, Esteban A. Maringolo [*] Several years ago I took a private course of mobile squeak, and even compiled a modified squeak VM for WinCE, running MVC based UIs. Back then Squeak UI was way better than WinCE's, even for business apps. Now I think mobile expectations changed.
Re: [Pharo-dev] Where is the postcard with syntax?
2014-06-19 16:44 GMT+02:00 Dennis Schetinin chae...@gmail.com: Simple ~= Easy. Smalltalk is simple (simpler then most of other PLs), but it's not easy (to understand and master, especially after other PLs). Intersting... I'm certainly too biased after all these years of Smalltalk, but I would have thought the exact contrary... What exactly isn't easy in Smalltalk versus other PL? Is understanding and mastering C++, lisp, haskell, whatever, simpler than Smalltalk? Or do you only mean that difference between any two other languages is less than difference to Smalltalk? -- Best regards, Dennis Schetinin 2014-06-17 11:59 GMT+04:00 kilon alios kilon.al...@gmail.com: personally I don't like this postcard , it looks too much like snake oil marketing to me. It creates the illusion that Pharo is much simpler than other programming languages as a programming language while nothing can be further from the truth. The idea here is to prove to the viewer that Pharo is based on a very simple recipe and that is of course true. But if we have to be honest is should come with a disclaimer for the potential users that Pharo is no blue pill and there tons of things outside this postcard you need to learn if you want to create the simplest Pharo application. I will be frank , as a language I dont find Pharo any simpler than let's say python , which I am more familiar with. And the fact that there is this simple recipe gave me zero benefits to me so far. Its a cool trick that may come handy down the line if I want to shape the language more to my needs, but I dont see doing this to a day by day basis. Now a living coding postcard stating the workflow of Pharo and demonstrating the power of the debugger is much more honest and frankly better marketing for Pharo. You show something to a person that will benefit his workflow on a day by day basis. On Tue, Jun 17, 2014 at 10:32 AM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Now, who is creative enough to add “dynamic array” (one with curly braces) and temporaries in a block to the original thing: exampleWithNumber: x | y | true false not (nil isNil) ifFalse: [self halt]. y := self size + super size. #($a #a a 1 1.0) do: [ :each | Transcript show: (each class name); show: ' ']. ^x y Uko On 16 Jun 2014, at 15:35, Oscar Nierstrasz oscar.nierstr...@gmail.com wrote: I got it from Stef, who always said it came originally from Ralph Johnson. http://c2.com/cgi-bin/wiki?SmalltalkSyntaxInaPostcard Googling around finds various copies of this, but no original source. Oscar On 16 Jun 2014, at 10:58 , Yuriy Tymchuk yuriy.tymc...@me.com wrote: I guess it’s here: http://files.pharo.org/media/flyer-cheat-sheet.pdf I think that it would be interesting to put the syntax on a postcard. It can work as a proof of concept, some addition cheat-sheet for newcomers and also as some king of souvenir. Uko On 16 Jun 2014, at 10:36, stepharo steph...@free.fr wrote: you have the flyer of Damien (no idea where it is) but no real postcard. Stef On 16/6/14 09:35, Yuriy Tymchuk wrote: Hi guys, we all are talking about the syntax fitting in a postcard, but was there any real postcard with Pharo syntax prototype? This would be really interesting. Uko
Re: [Pharo-dev] Where is the postcard with syntax?
As I started Smalltalk with Pharo 1.3, I may resonate with Dennis point of view. Simple in syntax but not easy indeed. There are ways to do things and smart ways that require a while to sink in. Basically, it turned my mind upside down and I realised that a lot of things are easier to do in Smalltalk once you do it the Smalltalk way. And I really love the minimalism of the syntax and the environment. Heck, I chose to go with Pharo for my paying customers and it works fine. This explaining that, I'd better have a working solution if I want to eat. This helps with the learning. Not sure I would have persisted if it was not the case though. Phil On Thu, Jun 19, 2014 at 7:01 PM, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: 2014-06-19 16:44 GMT+02:00 Dennis Schetinin chae...@gmail.com: Simple ~= Easy. Smalltalk is simple (simpler then most of other PLs), but it's not easy (to understand and master, especially after other PLs). Intersting... I'm certainly too biased after all these years of Smalltalk, but I would have thought the exact contrary... What exactly isn't easy in Smalltalk versus other PL? Is understanding and mastering C++, lisp, haskell, whatever, simpler than Smalltalk? Or do you only mean that difference between any two other languages is less than difference to Smalltalk? -- Best regards, Dennis Schetinin 2014-06-17 11:59 GMT+04:00 kilon alios kilon.al...@gmail.com: personally I don't like this postcard , it looks too much like snake oil marketing to me. It creates the illusion that Pharo is much simpler than other programming languages as a programming language while nothing can be further from the truth. The idea here is to prove to the viewer that Pharo is based on a very simple recipe and that is of course true. But if we have to be honest is should come with a disclaimer for the potential users that Pharo is no blue pill and there tons of things outside this postcard you need to learn if you want to create the simplest Pharo application. I will be frank , as a language I dont find Pharo any simpler than let's say python , which I am more familiar with. And the fact that there is this simple recipe gave me zero benefits to me so far. Its a cool trick that may come handy down the line if I want to shape the language more to my needs, but I dont see doing this to a day by day basis. Now a living coding postcard stating the workflow of Pharo and demonstrating the power of the debugger is much more honest and frankly better marketing for Pharo. You show something to a person that will benefit his workflow on a day by day basis. On Tue, Jun 17, 2014 at 10:32 AM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Now, who is creative enough to add “dynamic array” (one with curly braces) and temporaries in a block to the original thing: exampleWithNumber: x | y | true false not (nil isNil) ifFalse: [self halt]. y := self size + super size. #($a #a a 1 1.0) do: [ :each | Transcript show: (each class name); show: ' ']. ^x y Uko On 16 Jun 2014, at 15:35, Oscar Nierstrasz oscar.nierstr...@gmail.com wrote: I got it from Stef, who always said it came originally from Ralph Johnson. http://c2.com/cgi-bin/wiki?SmalltalkSyntaxInaPostcard Googling around finds various copies of this, but no original source. Oscar On 16 Jun 2014, at 10:58 , Yuriy Tymchuk yuriy.tymc...@me.com wrote: I guess it’s here: http://files.pharo.org/media/flyer-cheat-sheet.pdf I think that it would be interesting to put the syntax on a postcard. It can work as a proof of concept, some addition cheat-sheet for newcomers and also as some king of souvenir. Uko On 16 Jun 2014, at 10:36, stepharo steph...@free.fr wrote: you have the flyer of Damien (no idea where it is) but no real postcard. Stef On 16/6/14 09:35, Yuriy Tymchuk wrote: Hi guys, we all are talking about the syntax fitting in a postcard, but was there any real postcard with Pharo syntax prototype? This would be really interesting. Uko
Re: [Pharo-dev] vm over android
A good place to run Pharo for IoT would be on an ARM-based Synology box. That would be a killer niche. Phil On Thu, Jun 19, 2014 at 6:35 PM, Esteban A. Maringolo emaring...@gmail.com wrote: Hi Clement, 2014-06-19 12:52 GMT-03:00 Clément Bera bera.clem...@gmail.com: 2014-06-18 15:39 GMT+02:00 Esteban A. Maringolo emaring...@gmail.com: Can you share what is the intended use of the android vm that you're building? - Deploying application on Android - Proving to big customers Pharo can run on ARM processor on the contrary to several other smalltalks What kind of applications? Is there an business interest of running on ARM processors? Is there a sale advantage of having this? I don't want to sound too inquisitive nor pedantic, those are real questions. As stated in previous mails, running on the platform is a technical challenge per se (I couldn't make it if I wanted), but it's just a very small part of deploying to Android. And I'm not talking about app stores. Even though Android (AOSP) is Linux based, the memory/battery constraints makes that apps or services lifecycle completely different to regular unix processes. And I don't see how this fits into the whole android environment. Last time I tried (+1yr) it the VM was a permanent process, without access to device sensors, etc.[*] I have a genuine interest in this topic, because my company depends both on Pharo and Android (native) software. But how I see this, the advantage of Pharo running on Android for devices other than phones/tablets, more kind of internet of things devices. The advantage is also that the image is an asset of the vm, so you can update your app without having to reinstall it through the platform app management. Please don't let this stop you guys from doing this VM even for the fun/sake of doing it. But as you are making this public, I feel allowed to ask questions and add comments. You can simply ignore them. :) Regards, Esteban A. Maringolo [*] Several years ago I took a private course of mobile squeak, and even compiled a modified squeak VM for WinCE, running MVC based UIs. Back then Squeak UI was way better than WinCE's, even for business apps. Now I think mobile expectations changed.
Re: [Pharo-dev] Where is the postcard with syntax?
As for me, Smalltalk was both really simple and easy at the time I met it many years ago. Maybe that's because I have been experiencing so many problems on the C++ way and have been looking for solutions… and Smalltalk had them all. But I have been teaching smalltalk for almost ten years by now, and I see that for the most of students (I would say for 90 – 95% of them) Smalltalk is not easy. I don't know why. I wonder why, actually. But that's how it is. And those who don't understand, who don't feel Smalltalk always says it's too complex. You see, they confuse it is complex with it is hard. And I think I saw exactly the same thing in that Kilon Alios's message. That's why I haven't manage not to answer :) What I wanted to say is that Smalltalk is really simple: it is based on few essential (and very human) ideas (there could be even fewer though), has a minimalistic syntax (could have even less syntax though I think). Other languages are much more complex. I don't know Python well, but I bet it's much more complex than Smalltalk. But when you do complex things day by day, for many years… they become easier. You just don't feel complexity anymore. It's still there, and it still hinders… but you don't see that anymore. And by now, any other, even much more simpler tool will be uncomfortable, strange… and hard. I think that's why most students do not embrace Smalltalk: it's different, it's unusual, it's strange… so I can admit: it's not easy. But please do not say it's complex! :) I believe these thoughts were inspired by some articles on easy vs. simple, simple is objective while easy is subjective etc. …They can be easily googled if need be. -- Best regards, Dennis Schetinin 2014-06-19 21:01 GMT+04:00 Nicolas Cellier nicolas.cellier.aka.n...@gmail.com: 2014-06-19 16:44 GMT+02:00 Dennis Schetinin chae...@gmail.com: Simple ~= Easy. Smalltalk is simple (simpler then most of other PLs), but it's not easy (to understand and master, especially after other PLs). Intersting... I'm certainly too biased after all these years of Smalltalk, but I would have thought the exact contrary... What exactly isn't easy in Smalltalk versus other PL? Is understanding and mastering C++, lisp, haskell, whatever, simpler than Smalltalk? Or do you only mean that difference between any two other languages is less than difference to Smalltalk? -- Best regards, Dennis Schetinin 2014-06-17 11:59 GMT+04:00 kilon alios kilon.al...@gmail.com: personally I don't like this postcard , it looks too much like snake oil marketing to me. It creates the illusion that Pharo is much simpler than other programming languages as a programming language while nothing can be further from the truth. The idea here is to prove to the viewer that Pharo is based on a very simple recipe and that is of course true. But if we have to be honest is should come with a disclaimer for the potential users that Pharo is no blue pill and there tons of things outside this postcard you need to learn if you want to create the simplest Pharo application. I will be frank , as a language I dont find Pharo any simpler than let's say python , which I am more familiar with. And the fact that there is this simple recipe gave me zero benefits to me so far. Its a cool trick that may come handy down the line if I want to shape the language more to my needs, but I dont see doing this to a day by day basis. Now a living coding postcard stating the workflow of Pharo and demonstrating the power of the debugger is much more honest and frankly better marketing for Pharo. You show something to a person that will benefit his workflow on a day by day basis. On Tue, Jun 17, 2014 at 10:32 AM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Now, who is creative enough to add “dynamic array” (one with curly braces) and temporaries in a block to the original thing: exampleWithNumber: x | y | true false not (nil isNil) ifFalse: [self halt]. y := self size + super size. #($a #a a 1 1.0) do: [ :each | Transcript show: (each class name); show: ' ']. ^x y Uko On 16 Jun 2014, at 15:35, Oscar Nierstrasz oscar.nierstr...@gmail.com wrote: I got it from Stef, who always said it came originally from Ralph Johnson. http://c2.com/cgi-bin/wiki?SmalltalkSyntaxInaPostcard Googling around finds various copies of this, but no original source. Oscar On 16 Jun 2014, at 10:58 , Yuriy Tymchuk yuriy.tymc...@me.com wrote: I guess it’s here: http://files.pharo.org/media/flyer-cheat-sheet.pdf I think that it would be interesting to put the syntax on a postcard. It can work as a proof of concept, some addition cheat-sheet for newcomers and also as some king of souvenir. Uko On 16 Jun 2014, at 10:36, stepharo steph...@free.fr wrote: you have the flyer of Damien (no idea where it is) but no real postcard. Stef On 16/6/14 09:35, Yuriy Tymchuk wrote: Hi
Re: [Pharo-dev] Where is the postcard with syntax?
I don't see how something that is simple cannot be easy unless its not really simple. So far I have not found Pharo simpler to Python. As a coding experience. Maybe if I stay around 10 year I will. I know there are things that Pharo / Smalltalk does better than Python like closure , or concepts associated with functional programming etc. But in the end of the day I don't care about languages that theoretically are great. I have not yet seen great gains in the language while I code, maybe because in the end of the day I just code in a very simplistic way, I am not a pro coder, I don't have the experience to use complex concepts like an experienced coder would do. I know a few things and that is what I use. But I don't stop learning . In the end of the day yes I find Smalltalk and Pharo much more difficult to Python because of the lack of documentation. Even books on Smalltalk seem to be decades old. Pharo has zero official reference documentation and I don't , like many others , like to read code , reading code is very very very slow. Did I just said that I don't like to read code, additionally I don't like to read code. I hate reading code with no comments. The syntax however is very simple. I also love that the syntax looks nothing like C, even though the vast majority of languages I know and I know most of the popular ones are C based. I never had a problem with the syntax. So I would say that Pharo is by far the type of language I love to read, if we exclude the fact that I don't like to read code and I hate reading uncommented code. So I cannot relate to your students, I don't see how anyone can see Smalltalk as complex at least on a syntax level unless he does not real understand what he learned. I am here however because I have fallen in love with live coding and the Smalltalk IDE. I was blown away with emacs but one day I asked at #emacs in IRC hey guys would not be awesome if emacs had GUIs and a full blown language and the answer I got try Squeak , Oh its a lisp thing , No its smalltalk, what on earth is smalltalk ? and the rest is history. I would say that language-wise Smalltalk is by far the easiest language I have learned. But as a coding experience is hard because of lack of documentation, lack of good documentation and lack of libraries. I think however Pharo deserves to be loads more popular, its a very good effort and me and Pharo seem to have the same goals in terms of coding. Elegance and directness. I don't care so much about simplicity because nothing in this world is really simple, not ease of use because nothing worth doing is easy to do. For me elegance is doing the complex thing the simplest way possible without compromising and directness means do it now, zero delays, zero excuses. It seems to me Pharo is build on these ideals and I would be around as long as it follows them. On Thu, Jun 19, 2014 at 8:52 PM, Dennis Schetinin chae...@gmail.com wrote: As for me, Smalltalk was both really simple and easy at the time I met it many years ago. Maybe that's because I have been experiencing so many problems on the C++ way and have been looking for solutions… and Smalltalk had them all. But I have been teaching smalltalk for almost ten years by now, and I see that for the most of students (I would say for 90 – 95% of them) Smalltalk is not easy. I don't know why. I wonder why, actually. But that's how it is. And those who don't understand, who don't feel Smalltalk always says it's too complex. You see, they confuse it is complex with it is hard. And I think I saw exactly the same thing in that Kilon Alios's message. That's why I haven't manage not to answer :) What I wanted to say is that Smalltalk is really simple: it is based on few essential (and very human) ideas (there could be even fewer though), has a minimalistic syntax (could have even less syntax though I think). Other languages are much more complex. I don't know Python well, but I bet it's much more complex than Smalltalk. But when you do complex things day by day, for many years… they become easier. You just don't feel complexity anymore. It's still there, and it still hinders… but you don't see that anymore. And by now, any other, even much more simpler tool will be uncomfortable, strange… and hard. I think that's why most students do not embrace Smalltalk: it's different, it's unusual, it's strange… so I can admit: it's not easy. But please do not say it's complex! :) I believe these thoughts were inspired by some articles on easy vs. simple, simple is objective while easy is subjective etc. …They can be easily googled if need be. -- Best regards, Dennis Schetinin 2014-06-19 21:01 GMT+04:00 Nicolas Cellier nicolas.cellier.aka.n...@gmail.com: 2014-06-19 16:44 GMT+02:00 Dennis Schetinin chae...@gmail.com: Simple ~= Easy. Smalltalk is simple (simpler then most of other PLs), but it's not easy (to understand and master, especially after other PLs).
Re: [Pharo-dev] vm over android
I got an iPhone for my father recently and he was blown away by the capabilities of the device I was describing him. Then I was surprised by the fact he was surprised. Then I took a step back and tried to be in his place. Then I was blown away too. Here is this 70 year old man, he is used to mobile phones which are basically phones that call other mobile phones and . well... thats it! Compared to an iPhone which is thousands times more powerful than my first computer. He told me to get him the adaptor for TV, so he can see things from his iPhone to his TV (watch football matches and youtube videos). I had already done a search and I found plenty of keyboards and mouses for iPhone. It makes you sit back and ask Mr Desktop / Laptop why we need you ? For me it makes sense to have a desktop or a laptop because I do 3d graphics and I need the power of a powerful desktop GPU which can run circles around any GPU used for smartphones and tablets. So desktop/laptop is a mandatory. But I am the exception , I am the freak. If computational power is not an issues, which is not for the vast majority of users out there. The size of the screen is not an issue because you can connect it to any modern screen and TV you want, the lack of keyboard is not because you can connect an external keyboard and lack of mouse is not because you can connect a mouse as well. And not to sound out of topic VM on Android is the single most important thing for the future of Pharo. Mobile market wont become smaller it will become much larger. Because smartphones are really lately that have turned into a full blow computers and people slowly realize it. How long before most of those people realize that they dont need their desktop ? Software migrates/ported constantly. I definetly would love to have Pharo on my Nexus 4 one day and run smoothly. I know its a lot of work, I don't expect it to happen any time soon, but when the time will come my mobile phone will be Pharo Powered ;) On Thu, Jun 19, 2014 at 8:52 PM, p...@highoctane.be p...@highoctane.be wrote: A good place to run Pharo for IoT would be on an ARM-based Synology box. That would be a killer niche. Phil On Thu, Jun 19, 2014 at 6:35 PM, Esteban A. Maringolo emaring...@gmail.com wrote: Hi Clement, 2014-06-19 12:52 GMT-03:00 Clément Bera bera.clem...@gmail.com: 2014-06-18 15:39 GMT+02:00 Esteban A. Maringolo emaring...@gmail.com: Can you share what is the intended use of the android vm that you're building? - Deploying application on Android - Proving to big customers Pharo can run on ARM processor on the contrary to several other smalltalks What kind of applications? Is there an business interest of running on ARM processors? Is there a sale advantage of having this? I don't want to sound too inquisitive nor pedantic, those are real questions. As stated in previous mails, running on the platform is a technical challenge per se (I couldn't make it if I wanted), but it's just a very small part of deploying to Android. And I'm not talking about app stores. Even though Android (AOSP) is Linux based, the memory/battery constraints makes that apps or services lifecycle completely different to regular unix processes. And I don't see how this fits into the whole android environment. Last time I tried (+1yr) it the VM was a permanent process, without access to device sensors, etc.[*] I have a genuine interest in this topic, because my company depends both on Pharo and Android (native) software. But how I see this, the advantage of Pharo running on Android for devices other than phones/tablets, more kind of internet of things devices. The advantage is also that the image is an asset of the vm, so you can update your app without having to reinstall it through the platform app management. Please don't let this stop you guys from doing this VM even for the fun/sake of doing it. But as you are making this public, I feel allowed to ask questions and add comments. You can simply ignore them. :) Regards, Esteban A. Maringolo [*] Several years ago I took a private course of mobile squeak, and even compiled a modified squeak VM for WinCE, running MVC based UIs. Back then Squeak UI was way better than WinCE's, even for business apps. Now I think mobile expectations changed.
Re: [Pharo-dev] Improving Pharo By Example
Yes I have not been doing that because I was lazy and struggling with the Pier syntax, but now I have learned good enough I will do it the way you say from now on. On Thu, Jun 19, 2014 at 4:48 PM, Damien Cassou damien.cas...@gmail.com wrote: On Thu, Jun 19, 2014 at 3:39 PM, kilon alios kilon.al...@gmail.com wrote: ok I leave it to your capable hands and I will try to position images at the start of the page , though that is easier said than done :D no! Don't do anything like that. LaTeX is capable of doing it by itself. You don't know where the page boundaries will be so it is hopeless for you :-). What you must ensure though, is that all figures are properly referenced in the text. This is a good example: ... bla... bla... see Figure *fig:myfig*. This is a bad example: ... bla... bla... see figure below: This is bad because you can't be sure the figure will be below (it can also be above, LaTeX decides). In any case chapters need proof reading so what I commit should never consider the final version. But I always try to produce as much quality as I can. No problem. -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
Re: [Pharo-dev] [ANN] Base62/Base36
Cool! It is a nice companion to my 8 byte pretty much unique generator [1], and could be integrated in my friendly URLs :). However, I couldn't prove the case insensitivity of Base36, the #toNumber: ignores characters not present in the Characters array. I fixed Base36 toNumber: but broke Base62 tests :) self assert: (Base36 toNumber: (Base36 fromNumber: 16) asUppercase) will fail. Regards, -- Esteban. [1] https://gist.github.com/eMaringolo/be973dcf03b0783711f1 Esteban A. Maringolo 2014-06-12 8:16 GMT-03:00 Norbert Hartl norb...@hartl.name: Hmm *cough* http://smalltalkhub.com/#!/~NorbertHartl/Base62 Norbert Am 12.06.2014 um 13:12 schrieb Norbert Hartl norb...@hartl.name: Just for the record. I’ve uploaded a package to smalltalkhub that contains util classes to en-/decode values into/from Base62/Base36. Base62/Base36 encode numbers in short strings. These are used e.g. by url shortener services from google, bit.ly etc. Base36 uses lowercase letters and numbers to encode, Base62 uses all characters from Base36 plus all uppercase letters. Base62 produces smaller strings while Base36 produces case insensitive ones. Example: Base62 fromNumber: 10 - 'q0U‘ Base36 fromNumber: 10 - ‚255s' FYI, Norbert
[Pharo-dev] How to convert properyl an Athens Surface to a Form
Hi, I can't find it. #asForm message produce odd result for me. Hilaire
Re: [Pharo-dev] How to convert properyl an Athens Surface to a Form
I use asForm and it works for me. can you create a screenshot with the odd result it creates. 2014-06-19 21:58 GMT+02:00 Hilaire Fernandes hilaire.fernan...@gmail.com: Hi, I can't find it. #asForm message produce odd result for me. Hilaire
Re: [Pharo-dev] vm over android
Hi Kilon, 2014-06-19 16:17 GMT-03:00 kilon alios kilon.al...@gmail.com: And not to sound out of topic VM on Android is the single most important thing for the future of Pharo. Mobile market wont become smaller it will become much larger. Because smartphones are really lately that have turned into a full blow computers and people slowly realize it. I disagree here. As an example, Android is switching its JIT runtime for an AOT one, because with JIT the performance (mostly related with UI perception) is slower than its iOS counterpart even when running on better hardware. Most of the popular apps use native multithreading intensively to maximize responsiveness. Pharo (as an organization) can't compete with that level of optimization, it doesn't have the budget for it. How long before most of those people realize that they dont need their desktop ? Software migrates/ported constantly. Most people already realized that. But, IMO, the trend is not to move to mobile devices, but to cloud as a platform, or more exactly as a concept of always available and ubiquitous. Mobile is an enabler of ubiquity, it's not the end platform, and the cambric explosion of devices is a proof of that (phones, tablets, tvs, wearables, cars, who knows what...). Checkout a few cloud based IDEs to see what you can do today with those (eg: https://c9.io/ , https://codenvy.com/) Amber's Helios IDE is something that could enable that, backed by Pharo. I definetly would love to have Pharo on my Nexus 4 one day and run smoothly. I know its a lot of work, I don't expect it to happen any time soon, but when the time will come my mobile phone will be Pharo Powered ;) Do you really want to have Pharo (for development) in a 5 screen? Or even in a 10 tablet? Have you tried using it? I did, and played around for a while. It was impressive that it ran bit identically. But that's all. Today's Pharo UI isn't close to be mobile ready, in terms of UI design, architecture and by consequence performance. I don't find this a problem at all... unless you want to target mobile platforms. I mean... no one complains node.js doesn't have a good UI, and if there are some, it isn't their main strength. I'm not aware of a trend to have IntelliJ/Eclipse and/or XCode running on mobile devices, even when there is less technology impedance between their programming language and the supporting platform. Having all that said, I see use for Pharo in the mobile, in internet of things as mentioned earlier, for intensive custom UI apps and for games, where there is no expectation of a native UI. Another handy usage would be to use it's self containment as an advantage to have a portable server stack or similar (assuming there is no dependency to local databases, etc.). And that's why when somebody says they're working on a VM for a mobile platform I ask what for?, because I'd love to be proved wrong and learn about an unseen use case that could give us, Pharoers and Smalltalkers in general, an advantage. Regards,
Re: [Pharo-dev] Where is the postcard with syntax?
On 19 Jun 2014, at 21:01, kilon alios kilon.al...@gmail.com wrote: I don't see how something that is simple cannot be easy unless its not really simple. So far I have not found Pharo simpler to Python. As a coding experience. Maybe if I stay around 10 year I will. I know there are things that Pharo / Smalltalk does better than Python like closure , or concepts associated with functional programming etc. But in the end of the day I don't care about languages that theoretically are great. I have not yet seen great gains in the language while I code, maybe because in the end of the day I just code in a very simplistic way, I am not a pro coder, I don't have the experience to use complex concepts like an experienced coder would do. I know a few things and that is what I use. But I don't stop learning . In the end of the day yes I find Smalltalk and Pharo much more difficult to Python because of the lack of documentation. Even books on Smalltalk seem to be decades old. Pharo has zero official reference documentation and I don't , like many others , like to read code , reading code is very very very slow. Did I just said that I don't like to read code, additionally I don't like to read code. I hate reading code with no comments. Reading well written code is an important way to make progress, IMHO. http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html First principle: Personal Mastery: If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual. Even though Linux is open-source I bet most of us have never read any kernel or system code. In Pharo, everything is easily accessible to a pretty low level - that is really amazing. Using senders, implementers and references to find what you want is a key skill. Of course, not every part of the system is as good an example, or written in such a way that it is easily understood - nor is everything documented. And granted, often it can be hard to get an overview. But we are moving forward in the right direction. The syntax however is very simple. I also love that the syntax looks nothing like C, even though the vast majority of languages I know and I know most of the popular ones are C based. I never had a problem with the syntax. So I would say that Pharo is by far the type of language I love to read, if we exclude the fact that I don't like to read code and I hate reading uncommented code. So I cannot relate to your students, I don't see how anyone can see Smalltalk as complex at least on a syntax level unless he does not real understand what he learned. I am here however because I have fallen in love with live coding and the Smalltalk IDE. I was blown away with emacs but one day I asked at #emacs in IRC hey guys would not be awesome if emacs had GUIs and a full blown language and the answer I got try Squeak , Oh its a lisp thing , No its smalltalk, what on earth is smalltalk ? and the rest is history. I would say that language-wise Smalltalk is by far the easiest language I have learned. But as a coding experience is hard because of lack of documentation, lack of good documentation and lack of libraries. I think however Pharo deserves to be loads more popular, its a very good effort and me and Pharo seem to have the same goals in terms of coding. Elegance and directness. I don't care so much about simplicity because nothing in this world is really simple, not ease of use because nothing worth doing is easy to do. For me elegance is doing the complex thing the simplest way possible without compromising and directness means do it now, zero delays, zero excuses. It seems to me Pharo is build on these ideals and I would be around as long as it follows them. On Thu, Jun 19, 2014 at 8:52 PM, Dennis Schetinin chae...@gmail.com wrote: As for me, Smalltalk was both really simple and easy at the time I met it many years ago. Maybe that's because I have been experiencing so many problems on the C++ way and have been looking for solutions… and Smalltalk had them all. But I have been teaching smalltalk for almost ten years by now, and I see that for the most of students (I would say for 90 – 95% of them) Smalltalk is not easy. I don't know why. I wonder why, actually. But that's how it is. And those who don't understand, who don't feel Smalltalk always says it's too complex. You see, they confuse it is complex with it is hard. And I think I saw exactly the same thing in that Kilon Alios's message. That's why I haven't manage not to answer :) What I wanted to say is that Smalltalk is really simple: it is based on few essential (and very human) ideas (there could be even fewer though), has a minimalistic syntax (could have even less syntax though I think). Other languages are much more complex. I don't know Python well, but I bet it's much more complex than Smalltalk. But when
Re: [Pharo-dev] Where is the postcard with syntax?
2014-06-19 22:21 GMT+02:00 Sven Van Caekenberghe s...@stfx.eu: On 19 Jun 2014, at 21:01, kilon alios kilon.al...@gmail.com wrote: I don't see how something that is simple cannot be easy unless its not really simple. So far I have not found Pharo simpler to Python. As a coding experience. Maybe if I stay around 10 year I will. I know there are things that Pharo / Smalltalk does better than Python like closure , or concepts associated with functional programming etc. But in the end of the day I don't care about languages that theoretically are great. I have not yet seen great gains in the language while I code, maybe because in the end of the day I just code in a very simplistic way, I am not a pro coder, I don't have the experience to use complex concepts like an experienced coder would do. I know a few things and that is what I use. But I don't stop learning . In the end of the day yes I find Smalltalk and Pharo much more difficult to Python because of the lack of documentation. Even books on Smalltalk seem to be decades old. Pharo has zero official reference documentation and I don't , like many others , like to read code , reading code is very very very slow. Did I just said that I don't like to read code, additionally I don't like to read code. I hate reading code with no comments. Reading well written code is an important way to make progress, IMHO. http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html First principle: Personal Mastery: If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual. Even though Linux is open-source I bet most of us have never read any kernel or system code. In Pharo, everything is easily accessible to a pretty low level - that is really amazing. Using senders, implementers and references to find what you want is a key skill. Of course, not every part of the system is as good an example, or written in such a way that it is easily understood - nor is everything documented. And granted, often it can be hard to get an overview. But we are moving forward in the right direction. Yep, I forgot that I learned with Smalltalk/V and st80... I think I had read all the code base after two or three years, blue book included. Learning with Squeak/Pharo certainly put the hurdle a bit high... I don't think I will ever read the whole... I'd say maybe try and teach with Cuis? The syntax however is very simple. I also love that the syntax looks nothing like C, even though the vast majority of languages I know and I know most of the popular ones are C based. I never had a problem with the syntax. So I would say that Pharo is by far the type of language I love to read, if we exclude the fact that I don't like to read code and I hate reading uncommented code. So I cannot relate to your students, I don't see how anyone can see Smalltalk as complex at least on a syntax level unless he does not real understand what he learned. I am here however because I have fallen in love with live coding and the Smalltalk IDE. I was blown away with emacs but one day I asked at #emacs in IRC hey guys would not be awesome if emacs had GUIs and a full blown language and the answer I got try Squeak , Oh its a lisp thing , No its smalltalk, what on earth is smalltalk ? and the rest is history. I would say that language-wise Smalltalk is by far the easiest language I have learned. But as a coding experience is hard because of lack of documentation, lack of good documentation and lack of libraries. I think however Pharo deserves to be loads more popular, its a very good effort and me and Pharo seem to have the same goals in terms of coding. Elegance and directness. I don't care so much about simplicity because nothing in this world is really simple, not ease of use because nothing worth doing is easy to do. For me elegance is doing the complex thing the simplest way possible without compromising and directness means do it now, zero delays, zero excuses. It seems to me Pharo is build on these ideals and I would be around as long as it follows them. On Thu, Jun 19, 2014 at 8:52 PM, Dennis Schetinin chae...@gmail.com wrote: As for me, Smalltalk was both really simple and easy at the time I met it many years ago. Maybe that's because I have been experiencing so many problems on the C++ way and have been looking for solutions… and Smalltalk had them all. But I have been teaching smalltalk for almost ten years by now, and I see that for the most of students (I would say for 90 – 95% of them) Smalltalk is not easy. I don't know why. I wonder why, actually. But that's how it is. And those who don't understand, who don't feel Smalltalk always says it's too complex. You see, they confuse it is complex with it is hard. And I think I saw exactly the same thing in that Kilon Alios's message. That's why I haven't manage not to answer :) What I wanted to say
Re: [Pharo-dev] [ANN] Base62/Base36
Thanks Norbert, This is a nice library! Alexandre On Jun 12, 2014, at 7:12 AM, Norbert Hartl norb...@hartl.name wrote: Just for the record. I’ve uploaded a package to smalltalkhub that contains util classes to en-/decode values into/from Base62/Base36. Base62/Base36 encode numbers in short strings. These are used e.g. by url shortener services from google, bit.ly etc. Base36 uses lowercase letters and numbers to encode, Base62 uses all characters from Base36 plus all uppercase letters. Base62 produces smaller strings while Base36 produces case insensitive ones. Example: Base62 fromNumber: 10 - 'q0U‘ Base36 fromNumber: 10 - ‚255s' FYI, Norbert -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] Where is the postcard with syntax?
On Thu, Jun 19, 2014 at 1:37 PM, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: 2014-06-19 22:21 GMT+02:00 Sven Van Caekenberghe s...@stfx.eu: On 19 Jun 2014, at 21:01, kilon alios kilon.al...@gmail.com wrote: I don't see how something that is simple cannot be easy unless its not really simple. So far I have not found Pharo simpler to Python. As a coding experience. Maybe if I stay around 10 year I will. I know there are things that Pharo / Smalltalk does better than Python like closure , or concepts associated with functional programming etc. But in the end of the day I don't care about languages that theoretically are great. I have not yet seen great gains in the language while I code, maybe because in the end of the day I just code in a very simplistic way, I am not a pro coder, I don't have the experience to use complex concepts like an experienced coder would do. I know a few things and that is what I use. But I don't stop learning . In the end of the day yes I find Smalltalk and Pharo much more difficult to Python because of the lack of documentation. Even books on Smalltalk seem to be decades old. Pharo has zero official reference documentation and I don't , like many others , like to read code , reading code is very very very slow. Did I just said that I don't like to read code, additionally I don't like to read code. I hate reading code with no comments. Great first part of your comment Kilon. Yes, the language is far simpler, but the libraries, oh the libraries, and the doc. But doc is not necessarily the problem. Examples can be good. There needs to be lots of effort put into tutorials, examples, etc. But I have to say that reading code can be a joy, and really educational, even if with no comments, _provided_ it is well-written. That's one of the things that's really special about SMalltalk, support for reading, both in the syntax and in the tools (senders, implementors, class comments). Get over your antipathy and read as much as you can. Its a good route to mastery. Reading well written code is an important way to make progress, IMHO. +1 http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html First principle: Personal Mastery: If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual. Even though Linux is open-source I bet most of us have never read any kernel or system code. In Pharo, everything is easily accessible to a pretty low level - that is really amazing. Using senders, implementers and references to find what you want is a key skill. Of course, not every part of the system is as good an example, or written in such a way that it is easily understood - nor is everything documented. And granted, often it can be hard to get an overview. But we are moving forward in the right direction. Yep, I forgot that I learned with Smalltalk/V and st80... I think I had read all the code base after two or three years, blue book included. Learning with Squeak/Pharo certainly put the hurdle a bit high... I don't think I will ever read the whole... I'd say maybe try and teach with Cuis? Good idea. Learning with Smalltalk-80 V2 was such a joy. You could read and understand everything. It led to a feeling of mastery. Being able to hack the compiler, modify tools, etc. Lovely. Small is beautiful. The syntax however is very simple. I also love that the syntax looks nothing like C, even though the vast majority of languages I know and I know most of the popular ones are C based. I never had a problem with the syntax. So I would say that Pharo is by far the type of language I love to read, if we exclude the fact that I don't like to read code and I hate reading uncommented code. So I cannot relate to your students, I don't see how anyone can see Smalltalk as complex at least on a syntax level unless he does not real understand what he learned. I am here however because I have fallen in love with live coding and the Smalltalk IDE. I was blown away with emacs but one day I asked at #emacs in IRC hey guys would not be awesome if emacs had GUIs and a full blown language and the answer I got try Squeak , Oh its a lisp thing , No its smalltalk, what on earth is smalltalk ? and the rest is history. I would say that language-wise Smalltalk is by far the easiest language I have learned. But as a coding experience is hard because of lack of documentation, lack of good documentation and lack of libraries. I think however Pharo deserves to be loads more popular, its a very good effort and me and Pharo seem to have the same goals in terms of coding. Elegance and directness. I don't care so much about simplicity because nothing in this world is really simple, not ease of use because nothing worth doing is easy to do. For me elegance is doing the complex thing the simplest way possible without compromising and directness means do it
Re: [Pharo-dev] vm over android
I disagree here. As an example, Android is switching its JIT runtime for an AOT one, because with JIT the performance (mostly related with UI perception) is slower than its iOS counterpart even when running on better hardware. Most of the popular apps use native multithreading intensively to maximize responsiveness. Pharo (as an organization) can't compete with that level of optimization, it doesn't have the budget for it. Its not about competition, its about hey guys may have a tiny slice of the cake ? I can ? thanks I will be here in my corner Also the more powerful the hardware will become the less need would be to have true multithreading. I am not saying its very important but lets face it even on a single core you can do pretty amazing stuff. Right now mobile devices are quite slow even for basic stuff but the hardware only gets faster. Do you really want to have Pharo (for development) in a 5 screen? Or even in a 10 tablet? Have you tried using it? I did, and played around for a while. It was impressive that it ran bit identically. But that's all. As I said you can connect your mobile device to any monitor you want, you want 20'' fine , 30'' sure, 40'' why not , 1000'' oh yeah as long it has an hdmi port. The bottom line is that almost everyone will have a smartphone phone . Is this a market as a pharo developer you want to tap in ? It already has happened in USA and most of Europe , even here in Greece with big economical crisis people buy mainly smartphones and some even spend substantial amounts. iPhones actually are pretty popular here too. I'm not aware of a trend to have IntelliJ/Eclipse and/or XCode running on mobile devices, even when there is less technology impedance between their programming language and the supporting platform. This is why I said we are not there yet, but is getting there. For example there is an Emacs port , though it requires external keyboard. Its not that it cannot be done, its more about moving a very big code base takes a lot of time and effort. But once again remember that its about the users not the developers. Developer did not move to the web because they like, actually most people I have talked to dislike and some even hate it. But its a very big market and a market with a very solid future in a world with economic uncertainty. 4 years ago, I remember arguing in music forums that music mobile apps will become serious tools even for professionals, back when ipad was first released, many people laughed at me, other though it was a possibility , some were sceptical . I was almost certain. 4 years later here we are, loads of music apps on mobile devices and their even artists that use solely mobile devices for music production with some help from Dekstops toos for final touches. What will happen in the next 4 years ? I was not successful trying Pharo , I tried Squeak but the multitouch was problematic as hell. Pharo claims its modern , but for me no language or software can claim that unless its taps to the mobile market. Unless the software is so demanding that it needs loads of raw performance that a mobile device cannot offer. But even that last front will slowly fall. Its not that Desktops will not be the fastest / most powerful option but mobile devices will become loads more powerful. Imagine what will happen if the smartphone of the future is 1000 times more powerful lets say in 30 years , imagine what you could do with that technology. Should Pharo see 30 years in the future ? If it has learned anything from the mistakes of Smalltalk , it should. About the cloud option, I have to say I am not a huge believer in cloud technology. I think for developed countries its a very good solution BUT many countries out there, including mine, have extremely unreliable internet connections. Browsers have seen this need and loads of options for offline storage has been offered, though it has become quite a confusing mess. So yeah cloud with offline storage is a good recipe , Pharo on the cloud is definetly a good option. Pharo + Amber is something I have recommended many times. So yes I agree with you there, but that does not make me dislike the idea of a VM on android and iOS. Why ? because web technology is a huge pile of mess, its a pain in the ass. Are Amber people going to wrap all this technology for us to make it easier to use ? probably not. So I still like to fully use Pharo. But Amber is a very good option too. So yes I think Pharo on mobile devices, however that happens is not the near future Pharo but its absolutely the distant future.
Re: [Pharo-dev] Where is the postcard with syntax?
I am not debating well written code. Readable code must always be the No 1 priority . The questions is can you really rely on it ? Because in the end design decisions will be made , or people will not agree on what beautiful code really is. So I think aim for beautiful code, expect ugly code, be realistic. Or as they say have head in the cloud and feet on the ground. I am also not debating the beauty of Smalltalk and Lisp. There is a reason so many things are copied from these languages. Objective C and Ruby state that are based on Smalltalk , so I definitely respect and appreciate what a simple syntax can do for a flexible expression of a coder. All I am saying is that people may dislike Smalltalk for things unrelated to the design of the code and the nature of the language. For me its documentation, for others may be other things. Its not as simple as simple syntax ;) On Fri, Jun 20, 2014 at 12:02 AM, Eliot Miranda eliot.mira...@gmail.com wrote: On Thu, Jun 19, 2014 at 1:37 PM, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: 2014-06-19 22:21 GMT+02:00 Sven Van Caekenberghe s...@stfx.eu: On 19 Jun 2014, at 21:01, kilon alios kilon.al...@gmail.com wrote: I don't see how something that is simple cannot be easy unless its not really simple. So far I have not found Pharo simpler to Python. As a coding experience. Maybe if I stay around 10 year I will. I know there are things that Pharo / Smalltalk does better than Python like closure , or concepts associated with functional programming etc. But in the end of the day I don't care about languages that theoretically are great. I have not yet seen great gains in the language while I code, maybe because in the end of the day I just code in a very simplistic way, I am not a pro coder, I don't have the experience to use complex concepts like an experienced coder would do. I know a few things and that is what I use. But I don't stop learning . In the end of the day yes I find Smalltalk and Pharo much more difficult to Python because of the lack of documentation. Even books on Smalltalk seem to be decades old. Pharo has zero official reference documentation and I don't , like many others , like to read code , reading code is very very very slow. Did I just said that I don't like to read code, additionally I don't like to read code. I hate reading code with no comments. Great first part of your comment Kilon. Yes, the language is far simpler, but the libraries, oh the libraries, and the doc. But doc is not necessarily the problem. Examples can be good. There needs to be lots of effort put into tutorials, examples, etc. But I have to say that reading code can be a joy, and really educational, even if with no comments, _provided_ it is well-written. That's one of the things that's really special about SMalltalk, support for reading, both in the syntax and in the tools (senders, implementors, class comments). Get over your antipathy and read as much as you can. Its a good route to mastery. Reading well written code is an important way to make progress, IMHO. +1 http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html First principle: Personal Mastery: If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual. Even though Linux is open-source I bet most of us have never read any kernel or system code. In Pharo, everything is easily accessible to a pretty low level - that is really amazing. Using senders, implementers and references to find what you want is a key skill. Of course, not every part of the system is as good an example, or written in such a way that it is easily understood - nor is everything documented. And granted, often it can be hard to get an overview. But we are moving forward in the right direction. Yep, I forgot that I learned with Smalltalk/V and st80... I think I had read all the code base after two or three years, blue book included. Learning with Squeak/Pharo certainly put the hurdle a bit high... I don't think I will ever read the whole... I'd say maybe try and teach with Cuis? Good idea. Learning with Smalltalk-80 V2 was such a joy. You could read and understand everything. It led to a feeling of mastery. Being able to hack the compiler, modify tools, etc. Lovely. Small is beautiful. The syntax however is very simple. I also love that the syntax looks nothing like C, even though the vast majority of languages I know and I know most of the popular ones are C based. I never had a problem with the syntax. So I would say that Pharo is by far the type of language I love to read, if we exclude the fact that I don't like to read code and I hate reading uncommented code. So I cannot relate to your students, I don't see how anyone can see Smalltalk as complex at least on a syntax level unless he does not real understand what he learned. I am here however because I
[Pharo-dev] Configuration Browser and Pharo4
How can I make configurations from MetaRepoPharo30 work on Pharo4? I have switched the Repository from MetaRepoPhar40 to MetaRepoPharo30 and tried to load NaCl (Install stable version). It fails with 'Name not found: FFI' And ConfigurationOfFFI doesn't load either. btw, If I loaded a ConfigurationOfXXX how do I know what versions are loadable? Should all ConfigurationOf projects have the same symbolic versions (development/stable/ ...) regards Nicolai
Re: [Pharo-dev] Configuration Browser and Pharo4
you can change #metacelloPlatformAttributes to accept Pharo3 stable versions. … at your own risk, of course :) Esteban On 19 Jun 2014, at 18:31, Nicolai Hess nicolaih...@web.de wrote: How can I make configurations from MetaRepoPharo30 work on Pharo4? I have switched the Repository from MetaRepoPhar40 to MetaRepoPharo30 and tried to load NaCl (Install stable version). It fails with 'Name not found: FFI' And ConfigurationOfFFI doesn't load either. btw, If I loaded a ConfigurationOfXXX how do I know what versions are loadable? Should all ConfigurationOf projects have the same symbolic versions (development/stable/ ...) regards Nicolai
Re: [Pharo-dev] Configuration Browser and Pharo4
Great, it works. Thank you. 2014-06-19 23:34 GMT+02:00 Esteban Lorenzano esteba...@gmail.com: you can change #metacelloPlatformAttributes to accept Pharo3 stable versions. … at your own risk, of course :) Esteban On 19 Jun 2014, at 18:31, Nicolai Hess nicolaih...@web.de wrote: How can I make configurations from MetaRepoPharo30 work on Pharo4? I have switched the Repository from MetaRepoPhar40 to MetaRepoPharo30 and tried to load NaCl (Install stable version). It fails with 'Name not found: FFI' And ConfigurationOfFFI doesn't load either. btw, If I loaded a ConfigurationOfXXX how do I know what versions are loadable? Should all ConfigurationOf projects have the same symbolic versions (development/stable/ ...) regards Nicolai
[Pharo-dev] Athens and StrikeFont ( again )
If I take a fresh pharo image I always have to reenable FT fonts before doing any athens rendering with text (RMOD StrikeFont(Object)doesNotUnderstand: #getPreciseHeight). Ok, I know I have to open settings disable then enable FreeType and choose a FreeType font. But what exactly is the problem with Athens rendering and non FT fonts? Nicolai
Re: [Pharo-dev] Athens and StrikeFont ( again )
Times to times, font are displayed in a very weir fashion: small and big letter. Width is not properly computed in addition. Alexandre Le 19-06-2014 à 18:26, Nicolai Hess nicolaih...@web.de a écrit : If I take a fresh pharo image I always have to reenable FT fonts before doing any athens rendering with text (RMOD StrikeFont(Object)doesNotUnderstand: #getPreciseHeight). Ok, I know I have to open settings disable then enable FreeType and choose a FreeType font. But what exactly is the problem with Athens rendering and non FT fonts? Nicolai
Re: [Pharo-dev] Implementing cull:cull: in symbol
On Thu, Jun 19, 2014 at 11:24:33AM -0300, Esteban A. Maringolo wrote: Can somebody please tell me the semantic difference between #cull: and #value: ? 'Cull' is not a word I ever used in any english based conversation :) Hi Esteban, I am an American English speaker, and I have never used the word 'cull' in conversation or in writing. I recognize it as a real word, but I had to look it up in a dictionary to see what it means. Dave
