- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Vm on Mac OS 7.5 no cairo

by Esteban Lorenzano

On 19 Jun 2014, at 09:35, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 19 Jun 2014, at 09:03, Guillermo Polito <guillermopolito(a)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 <stephan(a)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 >> >> >> >

June 19, 2014

Re: [Pharo-dev] Vm on Mac OS 7.5 no cairo

by Esteban Lorenzano

On 19 Jun 2014, at 09:03, Guillermo Polito <guillermopolito(a)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 <stephan(a)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 > > >

June 19, 2014

Re: [Pharo-dev] Performance for Video Games(Woden Video)

by Sean P. DeNigris

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-tp4762913p476… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 19, 2014

Re: [Pharo-dev] Implementing cull:cull: in symbol

by Yuriy Tymchuk

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.johansen(a)veloxit.no> wrote: > > On 19 Jun 2014, at 1:42 , Yuriy Tymchuk <yuriy.tymchuk(a)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

June 19, 2014

Re: [Pharo-dev] Implementing cull:cull: in symbol

by Henrik Johansen

On 19 Jun 2014, at 1:42 , Yuriy Tymchuk <yuriy.tymchuk(a)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

June 19, 2014

Re: [Pharo-dev] Azure Storage Library

by Sven Van Caekenberghe

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.moutarde(a)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... > >

June 19, 2014

Re: [Pharo-dev] Vm on Mac OS 7.5 no cairo

by Guillermo Polito

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 <stephan(a)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 > > >

June 19, 2014

Re: [Pharo-dev] Implementing cull:cull: in symbol

by Yuriy Tymchuk

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 <sven(a)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.tymchuk(a)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 >> > >

June 19, 2014

Re: [Pharo-dev] Auto fill free space by widget in Spec

by Benjamin

In your morphic adapter, you probably missed hResizing: #spaceFill; vResizing: #spaceFill; Ben On 19 Jun 2014, at 13:56, Yuriy Tymchuk <yuriy.tymchuk(a)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

June 19, 2014

Auto fill free space by widget in Spec

by Yuriy Tymchuk

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

June 19, 2014