[Pharo-users] Workspace with reliable save feature

2020-01-22 Thread HilaireFernandes
Hi, 

Do we have an external workspace with a deterministic save feature.
I looked at the catalog but found none,

Both Workspace and Playground fall short.

Workspace save file with 0 byte of content!

Playground, with my experience with student, is absolutely not reliable to
save script, its auto-save feature always results in lost of code.
Particularly when combined with its rename and its inexplicit save
behaviour. It is not practical to edit script and save code.

I will start a second round of coding with students (12-14 yrs old) and I
need them to save their code. The only viable option I see is to ask them to
copy and to past their code in an external editor ! It will be a mess for
sure and waste of time and energy. 

Any alternative  idea or option I failed to see ?

Hilaire



-
http://drgeo.eu
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html



Re: [Pharo-users] Generate class hierarchy from JSON Schema

2020-01-22 Thread Todd Blanchard via Pharo-users
--- Begin Message ---
That would be amazing!

I'm a Mac/Unix guy so I don't have access to the other platforms (I suppose I 
could fire up an AWS Oracle).  I can do mysql/mariadb, posgresql, and sqlite.

I'm pretty close to pushing my ActiveRecord extensions.  I just need to get 
many to many with link tables done and it is good to go.  I spent a few days 
"porting" the ruby inflector and its tests.

As for database introspection, I am relying on this new method and the result 
set format on DatabasePlatform.

printSqlStatementToListColumnsInTable: aDatabaseTable inSchema: schemaString 
on: aStream
" Format:
   name   |   type| length | nullable | 
default_value | pk 
-+---++--+---+
 id  | character varying |255 |0 | 
''::character varying |  1 

Then I can build a whole class model and descriptor system off the schema.

> On Jan 22, 2020, at 9:55 AM, Tomaž Turk  wrote:
> 
> Thanks, Todd - I'll prepare a PR for https://github.com/pharo-rdbms/glorp 
>  to update SQLServerPlatform and 
> OraclePlatform.
> 
> I already used the standardized query results format in PharoADO which works 
> nicely with Glorp. You can find PharoADO here: 
> https://github.com/eftomi/pharo-ado . 
> Maybe it can be included into the pharo-rdbms collection if you feel that 
> it's mature enough. PharoADO can be used standalone (as interface to ActiveX 
> Data Objects) or with Glorp.
> 
> However, there are some "high level" tests in Glorp package that are still 
> red with Oracle and SQLServer, you can find the list on GitHub under 
> "issues". In particular, I didn't have time yet to implement blobs - PharoADO 
> uses PharoCOM (by Pablo) and firstly we have to settle the Variant SafeArray 
> data type in that package. Now that we have stable Pharo 8.0 64 bit for 
> Windows, PharoCOM should be checked for 64-bits, too. 
> 
> Anyway, I agree with you that the database support is one of the key success 
> factors for a development platform. I'm focusing into this since I hope that 
> one day I could teach the concepts of business solutions development fully in 
> Pharo :-)
> 
> Best wishes,
> Tomaz
> 
> 
> 
>> The official is https://github.com/pharo-rdbms/glorp (The one I forked at 
>> pharo-db - a username I need to change as it is causing confusion).
>>  
>> I've been mostly working with P3 and SQLite together. I've standardized the 
>> query results format for fetching field definitions so if you want to add 
>> support for another db, please note the format of the result set and 
>> structure yours appropriately.
>>  
>> I would very much like all the databases to be hosted under pharo-rdbms and 
>> all of them to have glorp adaptors and the additional meta structure queries 
>> I'm adding to the GlorpPlatform classes to enable ActiveRecord. I feel like 
>> Pharo's RDBMS story has been lagging and the lack of ready to go database 
>> support keeps people from building apps on it.
>>  
>> There are a zillion little business CRUD apps that could be knocked out with 
>> spec2 or Seaside.
>>  
>> Please, dive in and make improvements.

--- End Message ---


Re: [Pharo-users] Generate class hierarchy from JSON Schema

2020-01-22 Thread Tomaž Turk
Thanks, Todd - I'll prepare a PR for 
https://github.com/pharo-rdbms/glorp to update SQLServerPlatform and 
OraclePlatform.


I already used the standardized query results format in PharoADO which 
works nicely with Glorp. You can find PharoADO here: 
https://github.com/eftomi/pharo-ado. Maybe it can be included into the 
pharo-rdbms collection if you feel that it's mature enough. PharoADO can 
be used standalone (as interface to ActiveX Data Objects) or with Glorp.


However, there are some "high level" tests in Glorp package that are 
still red with Oracle and SQLServer, you can find the list on GitHub 
under "issues". In particular, I didn't have time yet to implement blobs 
- PharoADO uses PharoCOM (by Pablo) and firstly we have to settle the 
Variant SafeArray data type in that package. Now that we have stable 
Pharo 8.0 64 bit for Windows, PharoCOM should be checked for 64-bits, 
too.


Anyway, I agree with you that the database support is one of the key 
success factors for a development platform. I'm focusing into this since 
I hope that one day I could teach the concepts of business solutions 
development fully in Pharo :-)


Best wishes,
Tomaz




The official is https://github.com/pharo-rdbms/glorp (The one I forked at 
pharo-db - a username I need to change as it is causing confusion).

I've been mostly working with P3 and SQLite together.  I've standardized the 
query results format for fetching field definitions so if you want to add 
support for another db, please note the format of the result set and structure 
yours appropriately.

I would very much like all the databases to be hosted under pharo-rdbms and all 
of them to have glorp adaptors and the additional meta structure queries I'm 
adding to the GlorpPlatform classes to enable ActiveRecord.  I feel like 
Pharo's RDBMS story has been lagging and the lack of ready to go database 
support keeps people from building apps on it.

There are a zillion little business CRUD apps that could be knocked out with 
spec2 or Seaside.

Please, dive in and make improvements.


Re: [Pharo-users] Embedding pharo in C++

2020-01-22 Thread Roland Plüss via Pharo-users
--- Begin Message ---
I gave the C-Example repository a try but I don't fully understand how
it works. Does the vm_main_with_parameters() block until the VM is quit
or some function it runs? From looking at the source code I'm not sure
what it does.

On 1/22/20 12:17 PM, Pierce Ng wrote:
> On Wed, Jan 22, 2020 at 11:04:07AM +0100, teso...@gmail.com wrote:
>>nice to hear about the Pascal experiment, 
> I've published my code on GH and sent an announcement to pharo-dev.
>
> Repo is https://github.com/PierceNg/pharo-vm-embedded-pascal
>
> Pierce
>
>

-- 
Yours sincerely
Plüss Roland

Leader and Head Programmer
- Game: Epsylon ( http://www.indiedb.com/games/epsylon )
- Game Engine: Drag[en]gine ( http://www.indiedb.com/engines/dragengine
, http://dragengine.rptd.ch/wiki )
- As well as various Blender export scripts und game tools



signature.asc
Description: OpenPGP digital signature
--- End Message ---


[Pharo-users] [ANN] SmalltalkCI now supports Pharo 9

2020-01-22 Thread Gabriel Cotelli
Hi,
Just to let you know that smalltalkCI was updated to include Pharo 9, 32
and 64 bits as available versions to be used, and stable/alpha were updated
to be Pharo 8 and Pharo 9.

Thanks Pablo Tesone & Fabio Niephaus for helping in getting this updates
ready.

Regards,
Gabriel


Re: [Pharo-users] voyage mongo and transactionality

2020-01-22 Thread sebastianconcept
Hi guys,

I came to this post today due to having what can be described as an
unexpected voyage behavior and was greatly impressed by all the detailed
descriptions and explanations. Thanks everybody for that!

Also thanks Peter for mentioning that port I did back in the day (~2009) for
using OmniBase [1] in Aiflowing [2] where it achieved sub-second page
renderings with a full ACID, multi-image scalable setup. Is not actively
maintained but I think is a piece of software that is worth not having it
lost. The concept alone, filesystem based B-Tree object persistance, is neat
and can be the foundation of a lot of stuff.

Now I wonder what Esteban's fork has that couldn't be a merge request, I
would gladly take a look if open.

I feel bad about you loosing time with testBTreeKeyLocking because you won't
find the issue inside smalltalk. As it depends on the OS' file system to
detect concurrent changes in an object, you need the kernel of that system
to be supporting mandatory lockings [3] which is a feature that linux and
macOS does not have turned on by default. As mentioned in the readme of the
project you need to activate it in order to OmniBase raise an exception
preventing you of a race condition writing an object (coming it from a
transaction from another image or from another thread in that very image)
that would create db corruption or inconsistency. Note that, with mandatory
locking active in your OS kernel, the transaction that comes later will
raise an exception hence that test will pass. By the way, Windows has
mandatory locking by default.

*Back to the issue about voyage* here, I see the whole issue happening
simply because Voyage is caching by default hence forcing all Voyage users
to deal with one of the nastiest problems in computing: cache invalidation.

Yesterday I faced this issue: 
1. changed a mongo document from a mongo client and 
2. querying it from Voyage revealed different state (the state before 1).

This makes no sense at all. It makes Voyage not to be useful for
interoperation with other applications and languages, it makes it impossible
to scale an application in more than one Pharo image (all the main well
proven cloud platforms requires stateless built artifacts to horizontally
scale apps), on top of the lack of horizontal scaling issue there is the
issue of high availability that now you can't do because you are forced to
have a single point of failure (one vm behind the load balancer instead of
N).

But all those issues go away if Voyage simply does what a persistent client
is normally expected to do: save and query documents in the mongo
repository. By trying to do too much, like deciding that caching all inside
the session open in a given image is a valid design, it actually becomes
less powerful and surprises users in the worst way. Might be valid for a
prototype but certainly not for high-availability and high-load demanding
applications in production.

Caching is a great thing but is an application design decision, not a
persistency client decision. That concern is not for the client but for the
engineers who use it to make an application that might have /some/ of its
persisted models cached but certainly not all, except on very limited
scenarios. If you think about it, this is how things become niche.

Now in an application where I'm using Voyage expecting that queries return
what is actually in mongo I have to architect things in a way that
workaround this issue, like purging that cache somehow with some kind of
policy (time or a given event).

I like Voyage and I'm grateful for all the effort Esteban and the
contributors are putting into it. I might add a merge request myself. Is
documented, works well, has really nice features and is intuitive. It's just
this /cache all by default/ part that I don't think belongs to it and if
removed it would be a more powerful mongo client.



[1] https://github.com/sebastianconcept/OmniBase
[2] https://pharo.org/success/AirFlowing
[3] In *nix systems it requires mandatory file locking, so be sure you use
mand on your fstab.
https://www.hackinglinuxexposed.com/articles/20030623.html



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



Re: [Pharo-users] Embedding pharo in C++

2020-01-22 Thread Pierce Ng
On Wed, Jan 22, 2020 at 11:04:07AM +0100, teso...@gmail.com wrote:
>nice to hear about the Pascal experiment, 

I've published my code on GH and sent an announcement to pharo-dev.

Repo is https://github.com/PierceNg/pharo-vm-embedded-pascal

Pierce




Re: [Pharo-users] Embedding pharo in C++

2020-01-22 Thread Pierce Ng
On Wed, Jan 22, 2020 at 10:09:33AM +0100, teso...@gmail.com wrote:
> Hi, we are working on the tools required to have embedded Pharo in
> different solutions.

Hi Pablo,

Your published example embed the image as a Windows resource. Well, the
excellent and, like Smalltalk, vastly underrated Free Pascal has
built-in cross platform support for Windows resources.  Basically I have
implemented in Pascal the simplest FFI to libPharoVMCore and the
embedded image access routines for callback by libPharoVMCore, together
with a driver program which is pretty much a straight port of your C
program.

Pascal also produces static and dynamic libraries. My embedded image
access code can be packaged as such, which makes it accessible from
other languages.

> My idea is to implement an API to communicate to the image, I was
> thinking more in an API similar to Objective-C Bridge or COM objects.
> Still I am not sure how to design the API or the way to integrate it.
> Today, I am thinking about not having to much marsharlling of Pharo
> Objects to external objects, I am thinking to use a similar strategy
> like the used with FFI.

I am more thinking about marshaling, using say MessagePack. For 'over
the wire' development, maybe MessagePack RPC between headful Pharo and
the to-be-host program. For embedded, some means to pass MessagePack
structures back and forth.

Pierce



Re: [Pharo-users] Embedding pharo in C++

2020-01-22 Thread teso...@gmail.com
Hi, we are working on the tools required to have embedded Pharo in
different solutions.

My idea is to implement an API to communicate to the image, I was
thinking more in an API similar to Objective-C Bridge or COM objects.
Still I am not sure how to design the API or the way to integrate it.
Today, I am thinking about not having to much marsharlling of Pharo
Objects to external objects, I am thinking to use a similar strategy
like the used with FFI.

A simple start point begins with exposing callbacks from the image.
This will only work with the new Queue based callbacks, as the image
will receive callbacks from outside a call-out.

I have started with a POC of this, but time / resources is the
limitant. I will try to put some time on it, but we have other
priorities.

Cheers,


On Wed, Jan 22, 2020 at 9:38 AM Pierce Ng  wrote:
>
> On Tue, Jan 21, 2020 at 08:20:48PM +0100, Roland Plüss via Pharo-users wrote:
> > The first mode is the "runtime mode". This would be the mode used for
> > the released products and does not allow to "directly modify" the image.
> > This mode would only require basic set of classes (frameworks) since the
> > game engine provides a large set of functionality in the module layer so
> > the script layer provides the logic, UI and things like that. This image
> > would not require to be enriched with a lot of things.
>
> This is doable currently. The Pharo image is embedded into the
> executable and used in read-only mode. Although personally I'd implement
> as much of the app logic in Pharo as possible simply because of the high
> productivity.
>
> > The second mode is the "development mode". For this one I thought about
> > exposing a Pharo VM image acting as the Coding and Debugging IDE. Here I
> > would opt to expose the full power of Pharo/Smalltalk to the developer.
>
> I envisage doing this via some kind of data exchange between the host
> program and Pharo, which seems doable for both the embedded and 'over the
> wire' development cases.
>
> Pablo recently published an example of embedding a headless-but-GUI
> Pharo image inside a C program via the Windows resource mechanism. As it
> happens, I have just implemented the same example that works on Linux
> and MacOS from one source code. Didn't test on Windows, but I'm sure
> it'll work there too. In a day or two I will publish the code and blog
> post.
>
> Attached teaser screenshot. :-)
>
> Pierce
>


-- 
Pablo Tesone.
teso...@gmail.com



Re: [Pharo-users] Embedding pharo in C++

2020-01-22 Thread Pierce Ng
On Tue, Jan 21, 2020 at 08:20:48PM +0100, Roland Plüss via Pharo-users wrote:
> The first mode is the "runtime mode". This would be the mode used for
> the released products and does not allow to "directly modify" the image.
> This mode would only require basic set of classes (frameworks) since the
> game engine provides a large set of functionality in the module layer so
> the script layer provides the logic, UI and things like that. This image
> would not require to be enriched with a lot of things.

This is doable currently. The Pharo image is embedded into the
executable and used in read-only mode. Although personally I'd implement
as much of the app logic in Pharo as possible simply because of the high
productivity.

> The second mode is the "development mode". For this one I thought about
> exposing a Pharo VM image acting as the Coding and Debugging IDE. Here I
> would opt to expose the full power of Pharo/Smalltalk to the developer.

I envisage doing this via some kind of data exchange between the host
program and Pharo, which seems doable for both the embedded and 'over the
wire' development cases.

Pablo recently published an example of embedding a headless-but-GUI
Pharo image inside a C program via the Windows resource mechanism. As it
happens, I have just implemented the same example that works on Linux
and MacOS from one source code. Didn't test on Windows, but I'm sure
it'll work there too. In a day or two I will publish the code and blog
post.

Attached teaser screenshot. :-)

Pierce