Re: [Pharo-users] Standalone HTML Model (livecoded)

[Craig Latta]

 I wrote:

> I wasn't aware that one can livecode JS objects with PharoJS, only
> that PharoJS generates JS source which eventually runs in a browser.
> Can you give an example?

 Well, I evaluated the PharoJS playground expressions, and browsed
around the proxy support in the index.js that gets installed in a web
browser. I could inject the PjLoadForTest class into the web browser and
invoke its JS functions via Smalltalk messages from Pharo. I could send
#at:put: to the exposed "window" proxy of the web browser (as long as
the arguments were JS literals or proxies), and I could also inspect the
"document" proxy, but I got an exception when I tried to invoke
document.getElementWithId (via "bridge evalBlock: [document
getElementById: 'someID']"). Are arbitrary JS messages supposed to work?

 There isn't much exception handling support beyond relaying JS
error messages. (I guess one way to go would be to use the Chrome
Debugging Protocol.) I didn't see how to refer to Smalltalk objects from
JS (only JS objects from Smalltalk), so it seems the only Smalltalk
blocks one can use as JS callback functions are those which only use
objects and functions in JS-land.

 This might be okay for smoke-testing PharoJS apps, but I think the
kind of interactive DOM object sketching I mentioned before would be
uncomfortable.


-C

--
Craig Latta
Black Page Digital
Amsterdam :: San Francisco
cr...@blackpagedigital.com
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)

Re: [Pharo-users] Standalone HTML Model

[Craig Latta]

Hi Norbert--

> > In Pharo on the SqueakJS virtual machine in a web browser[1], I
> > sketch with live DOM objects, and write them out as HTML. This way,
> > the DSL is the actual JavaScript DOM API which is sitting in the web
> > browser anyway, although driven with Smalltalk messages over the JS
> > bridge. I'm also assured that everything I do with the DOM objects
> > is legitimate, and I can handle DOM API errors live in Smalltalk.
>
> Sure you can do the same with PharoJS.

 Really? I wasn't aware that one can livecode JS objects with
PharoJS, only that PharoJS generates JS source which eventually runs in
a browser. Can you give an example?

> But there are scenarios where you want to have DOM actions without
> having a browser.

 Oh, it wasn't clear to me that this was one of Sean's requirements.


 thanks,

-C

--
Craig Latta
Black Page Digital
Amsterdam :: San Francisco
cr...@blackpagedigital.com
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)

Re: [Pharo-users] UFFI problem / doubt

[Ben Coman]

Calling the wrapper function from Pharo the printf  "should"  output
to the console (at least on Unix platforms).
Shout if it doesn't.
cheers -ben

On Mon, Sep 18, 2017 at 9:41 PM, alvaro piorno
 wrote:
> Thanks Ben, i `ll try that.
>  Should "printf" print something on console while calling function form
> pharo or is only to check from C example?
>
>
> 2017-09-17 14:12 GMT-03:00 Ben Coman :
>>
>> On Mon, Sep 18, 2017 at 12:01 AM, alvaro piorno
>>  wrote:
>> > Pierce: I already see the repo, i kwnow now the difference and is not
>> > the
>> > problem i have now. I made the suggestion for book draft i found,
>> > because
>> > theres is no example on it. Thanks for answer.
>> >
>> > Stephan : Yes, as Esteban said i´m using that, I´m extending (or trying)
>> > Esteban´s project. And i´m having the problem that esteban metioned.
>> > Thanks
>> > for answer.
>> >
>> > Ben: I have in C the same example as in Pharo using the physics of
>> > Chipmunk,
>> > and in C is working fine, there is a problem in the call to the function
>> > from Pharo in 64 bits. Thanks for answer.
>>
>> Replicating the same example in C was not my point.
>> You'd said you'd already done that ;)
>>
>> I meant compile your own shared C library containing...
>> cpBody* myBodyNew(cpFloat m, cpFloat i))
>> {
>> printf( "\n", m, i );
>> cpBodyNew(cpFloat m, cpFloat i);
>> }
>>
>> and from Smalltalk use...
>> self ffiCall: #(cpBody* myBodyNew(cpFloat m, cpFloat i))
>>
>> also changing your existing C example to also use  myBodyNew()
>> to confirm it works as expected.
>>
>> cheers -ben
>>
>> >
>> >
>> > 2017-09-17 12:11 GMT-03:00 Ben Coman :
>> >>
>> >>
>> >> On Fri, Sep 15, 2017 at 9:42 PM, alvaro piorno
>> >> 
>> >> wrote:
>> >>>
>> >>> Hi everybody, i´m using UnifiedFFI with Chipmunk2D library .
>> >>> I want to get a pointer to a C Structure (cpBody) and set a position
>> >>> to
>> >>> it.
>> >>> I have a subClass of FFIOpaqueObject to handle pointer.
>> >>>
>> >>> This is the "new " ffiCall :
>> >>> self ffiCall: #(cpBody* cpBodyNew(cpFloat m, cpFloat i))
>> >>>
>> >>> And this is a "seter" ffiCall:
>> >>>
>> >>> self ffiCall: #( void cpBodySetPosition( self, cpVect vector ) ).
>> >>>
>> >>> I`m not getting any "error" but the position is not updating.
>> >>> I tried the same using Chipmunk directly and it works, so there is a
>> >>> problem with what i have in Pharo.
>> >>
>> >>
>> >> A general approach might be to write your own C wrapper around Chipmunk
>> >> library functions which
>> >> just does a debug printout of parameters before calling the wrapped
>> >> function.
>> >> Use these for both from Pharo and your "direct" trial, and see how they
>> >> compare.
>> >>
>> >> cheers -ben
>> >>
>> >
>>
>

Re: [Pharo-users] (no subject)

[Sean P. DeNigris]

demarey wrote
> It is a workaround but maybe I will add a strategy to use the unzip exe if
> I can find it on the system. That should solve most problems.
> WDYT?

Sounds like a reasonable workaround for now.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] UFFI problem / doubt

[alvaro piorno]

Thanks Ben, i `ll try that.
 Should "printf" print something on console while calling function form
pharo or is only to check from C example?


2017-09-17 14:12 GMT-03:00 Ben Coman :

> On Mon, Sep 18, 2017 at 12:01 AM, alvaro piorno
>  wrote:
> > Pierce: I already see the repo, i kwnow now the difference and is not the
> > problem i have now. I made the suggestion for book draft i found, because
> > theres is no example on it. Thanks for answer.
> >
> > Stephan : Yes, as Esteban said i´m using that, I´m extending (or trying)
> > Esteban´s project. And i´m having the problem that esteban metioned.
> Thanks
> > for answer.
> >
> > Ben: I have in C the same example as in Pharo using the physics of
> Chipmunk,
> > and in C is working fine, there is a problem in the call to the function
> > from Pharo in 64 bits. Thanks for answer.
>
> Replicating the same example in C was not my point.
> You'd said you'd already done that ;)
>
> I meant compile your own shared C library containing...
> cpBody* myBodyNew(cpFloat m, cpFloat i))
> {
> printf( "\n", m, i );
> cpBodyNew(cpFloat m, cpFloat i);
> }
>
> and from Smalltalk use...
> self ffiCall: #(cpBody* myBodyNew(cpFloat m, cpFloat i))
>
> also changing your existing C example to also use  myBodyNew()
> to confirm it works as expected.
>
> cheers -ben
>
> >
> >
> > 2017-09-17 12:11 GMT-03:00 Ben Coman :
> >>
> >>
> >> On Fri, Sep 15, 2017 at 9:42 PM, alvaro piorno <
> alvaropiorno...@gmail.com>
> >> wrote:
> >>>
> >>> Hi everybody, i´m using UnifiedFFI with Chipmunk2D library .
> >>> I want to get a pointer to a C Structure (cpBody) and set a position to
> >>> it.
> >>> I have a subClass of FFIOpaqueObject to handle pointer.
> >>>
> >>> This is the "new " ffiCall :
> >>> self ffiCall: #(cpBody* cpBodyNew(cpFloat m, cpFloat i))
> >>>
> >>> And this is a "seter" ffiCall:
> >>>
> >>> self ffiCall: #( void cpBodySetPosition( self, cpVect vector ) ).
> >>>
> >>> I`m not getting any "error" but the position is not updating.
> >>> I tried the same using Chipmunk directly and it works, so there is a
> >>> problem with what i have in Pharo.
> >>
> >>
> >> A general approach might be to write your own C wrapper around Chipmunk
> >> library functions which
> >> just does a debug printout of parameters before calling the wrapped
> >> function.
> >> Use these for both from Pharo and your "direct" trial, and see how they
> >> compare.
> >>
> >> cheers -ben
> >>
> >
>
>

Re: [Pharo-users] Web stack practices (Glorp / QCMagritte)

[jtuc...@objektfabrik.de]

Laurent,

I don't have answers to all your questions, but we use Glorp & Seaside 
(no Magritte) on VA Smalltalk for our cloud service (http://kontolino.de).




Am 18.09.17 um 12:22 schrieb laurent:

Hi all,

it's been a long time :) At work we are currently comparing several 
technologies to start a business project that will hopefully be used 
by thousands of people for several years ;)


We need a web stack and we put Pharo & co in the comparative process. 
My team have strong experience in  load-balanced php / mysql 
deployment that handles millions of records  but we are ready to build 
on something else though MySQL is still a requirement.

Sounds interesting.



Thanks for Garage + Glorp, I can prototype things. I wonder how to 
handle database schema migrations. With our PHP projects we have 
versionned PHP scripts that are automatically run given a database 
revision number ( see 
http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ). 
What are the practices with Glorp ?


We use a similar approach: our Descriptor class has a method called 
schemaVersion, which just returns the current version number. We also 
have a "magic" table for settings in our DB, just holding a "name" and a 
"value" column, both being Varchars. One of the rows has a name of 
"SchemaVersion" and the value is (you guessed it) the printString of the 
version number.


Our images accept a few command line paramters, one of them being 
--upgradeSchema. It compoares the number in the DB with the one provided 
by the descriptor. If they match, the image quits. If not, it calls all 
methods named #upgradeSchemaToVersionXXX until it reaches the number in 
the Descriptor. Thus we can do both SQL based migrations, like DDL 
stuff, as well as Smalltalk object based migrations (which can be sooo 
much faster to implement for complex cases). And we have all versioned 
and maintained in our beloved Envy repository ;-) .
The rest is just bash script magic (like only starting one image with 
the --upgradeSchema parameter and only start the real web workers once 
that one has ended succesfully).



About load balancing: You need Sticky sessions, so no failover between 
images. If one image crashes, the user must re-logon on a new image. 
Works nicely with Apache, I guess nginx works as least as well. For 
Apache, look for mod_prox_balancer to learn more.



Hope I could give you a few starting points for your research. And I 
also hope you'll find Pharo+Garage+Glorp+QCMagritte a good fit for your 
project. We all want success stories ;-)



Joachim

--
---
Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

Re: [Pharo-users] Web stack practices (Glorp / QCMagritte)

[Esteban A. Maringolo]

Laurent,

Regarding QCMagritte I don't know, since I don't use it. I've used
Magritte and Glorp, but didn't bind them, the only special thing I
built for it was an "evented memento" that let me edit a tree of
objects (1:N relations derived from the edited object) within a single
DB transaction.

Regarding migrations I recently found that in VisualWorks Glorp
provides a migration-like strategy, where you define a subclass of a
root Description system, and then can use the diffing to create the
migration.

According to the VW docs, you can do it like this:
sessOld := MyDescriptorSystem new sessionForLogin: aLogin.
sessNew := MyDescriptorSystem01 new sessionForLogin: aLogin.
sessOld system migrateTo: sessNew system.

Such feature is not available in the Pharo port, and migrations are
not automatic, since you need a new class for each migration.
It is something I'd need to play with before porting it to Pharo, if
it's worth it.
Maybe we think about another strategy but still using the DDL objects of Glorp.

Regards!

Esteban A. Maringolo


2017-09-18 7:22 GMT-03:00 laurent :
> Hi all,
>
> it's been a long time :) At work we are currently comparing several
> technologies to start a business project that will hopefully be used by
> thousands of people for several years ;)
>
> We need a web stack and we put Pharo & co in the comparative process. My
> team have strong experience in  load-balanced php / mysql deployment that
> handles millions of records  but we are ready to build on something else
> though MySQL is still a requirement.
>
> Thanks for Garage + Glorp, I can prototype things. I wonder how to handle
> database schema migrations. With our PHP projects we have versionned PHP
> scripts that are automatically run given a database revision number ( see
> http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ). What
> are the practices with Glorp ?
>
>
> We try QCMagritte and we enjoy what we see so far. What are the best
> practices to glue Magritte and Glorp together ? Especially when you
> load-balance requests on several images. Some examples ?
>
> ( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable
> version, MADescriptionBuilder missing. For #development versions of Magritte
> and QCMagritte, QCConfiguration missing ). So actually I use the one built
> on CI. )
>
>
> May be you have some other suggestions on a framework you love ?
>
>
> Best regards,
>
> Laurent Laffont
>
>
>
>
>

Re: [Pharo-users] Continued Fractions

[werner kassens]

Hi Phil,
yes, in polymath it is the the object PMContinuedFraction.
werner

On 09/17/2017 08:38 PM, p...@highoctane.be wrote:
> Ah, I see there is something in the Numerical Methods book. :rolleyes:
>
> Phil
>
> On Sun, Sep 17, 2017 at 8:30 PM, p...@highoctane.be
>   > wrote:
>
> Do we have anything related to continued fractions in Pharo?
>
> https://en.wikipedia.org/wiki/Continued_fraction
> 
>
> I need that to match rectanges to aspect ratios etc.
>
> TIA
> Phil
>
>

[Pharo-users] Web stack practices (Glorp / QCMagritte)

[laurent]

Hi all,

it's been a long time :) At work we are currently comparing several 
technologies to start a business project that will hopefully be used by 
thousands of people for several years ;)


We need a web stack and we put Pharo & co in the comparative process. 
My team have strong experience in  load-balanced php / mysql deployment 
that handles millions of records  but we are ready to build on 
something else though MySQL is still a requirement.


Thanks for Garage + Glorp, I can prototype things. I wonder how to 
handle database schema migrations. With our PHP projects we have 
versionned PHP scripts that are automatically run given a database 
revision number ( see 
http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ). 
What are the practices with Glorp ?



We try QCMagritte and we enjoy what we see so far. What are the best 
practices to glue Magritte and Glorp together ? Especially when you 
load-balance requests on several images. Some examples ?


( FYI, I cannot load QCMagritte in a fresh Pharo 6 image ( for #stable 
version, MADescriptionBuilder missing. For #development versions of 
Magritte and QCMagritte, QCConfiguration missing ). So actually I use 
the one built on CI. )



May be you have some other suggestions on a framework you love ?


Best regards,

Laurent Laffont

Re: [Pharo-users] (no subject)

[Christophe Demarey]

> Le 17 sept. 2017 à 05:21, Sean P. DeNigris  a écrit :
> 
> demarey wrote
>> Let us know if everything is fine. 
> 
> Was this issue [1] fixed:
>> I think I found it. It seems to be a bug in the way Launcher/Pharo unzips
>> the downloaded VM. 
>> The symlink libgit2.dylib becomes unlinked and appears as just a regular
>> file. If I delete the 
>> Pharo.app and unzip 70.zip (which btw maybe should have been deleted
>> during cleanup after 
>> the dl) to ./vms/70, the error disappears! 
> 
> [1] From
> http://forum.world.st/Launcher-Error-w-Pharo-7-tt4959777.html#a4960417

Not solved. 
Indeed, it is a problem of the Zip library that does not unzip properly (no 
preservation of permissions, does not handle symlinks).

It is a workaround but maybe I will add a strategy to use the unzip exe if I 
can find it on the system. That should solve most problems.
WDYT?

Re: [Pharo-users] Standalone HTML Model

[Norbert Hartl]

> Am 18.09.2017 um 09:03 schrieb Craig Latta :
> 
> 
> Hi Sean--
> 
>> I'd like to create HTML via a DSL, like Seaside's canvas builder, but
>> without loading a whole web framework. Any ideas?
> 
> In Pharo on the SqueakJS virtual machine in a web browser[1], I
> sketch with live DOM objects, and write them out as HTML. This way, the
> DSL is the actual JavaScript DOM API which is sitting in the web browser
> anyway, although driven with Smalltalk messages over the JS bridge. I'm
> also assured that everything I do with the DOM objects is legitimate,
> and I can handle DOM API errors live in Smalltalk.
> 
> 
Sure you can do the same with PharoJS. But there are scenarios where you want 
to have DOM actions without having a browser. You don't have that problem 
because you are in the browser

Norbert
> -C
> 
> [1] https://caffeine.js.org/pharo
> 
> --
> Craig Latta
> Black Page Digital
> Amsterdam :: San Francisco
> cr...@blackpagedigital.com
> +31   6 2757 7177 (SMS ok)
> + 1 415  287 3547 (no SMS)

Re: [Pharo-users] Standalone HTML Model

[Craig Latta]

Hi Sean--

> I'd like to create HTML via a DSL, like Seaside's canvas builder, but
> without loading a whole web framework. Any ideas?

 In Pharo on the SqueakJS virtual machine in a web browser[1], I
sketch with live DOM objects, and write them out as HTML. This way, the
DSL is the actual JavaScript DOM API which is sitting in the web browser
anyway, although driven with Smalltalk messages over the JS bridge. I'm
also assured that everything I do with the DOM objects is legitimate,
and I can handle DOM API errors live in Smalltalk.


-C

[1] https://caffeine.js.org/pharo

--
Craig Latta
Black Page Digital
Amsterdam :: San Francisco
cr...@blackpagedigital.com
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)