January 2020 - Pharo-users - lists.pharo.org

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

by 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. >

Jan. 22, 2020

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

by Roland PlÃ¼ss

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, tesonep(a)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

Jan. 22, 2020

[ANN] SmalltalkCI now supports Pharo 9

by 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

Jan. 22, 2020

Re: [Pharo-users] voyage mongo and transactionality

by 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

Jan. 22, 2020

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

by Pierce Ng

On Wed, Jan 22, 2020 at 11:04:07AM +0100, tesonep(a)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

Jan. 22, 2020

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

by tesonep＠gmail.com

Hi, nice to hear about the Pascal experiment, yes, that could be an alternative. I started to see how is the API for different embeddable runtimes. I want to have an API that allows us to continue having the power of the objects, I don't want to have strings passing from one side to the other. I will check MessagePack, thanks for the pointer. Cheers, Pablo On Wed, Jan 22, 2020 at 11:01 AM Pierce Ng <pierce(a)samadhiweb.com> wrote: > > On Wed, Jan 22, 2020 at 10:09:33AM +0100, tesonep(a)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 > -- Pablo Tesone. tesonep(a)gmail.com

Jan. 22, 2020

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

by Pierce Ng

On Wed, Jan 22, 2020 at 10:09:33AM +0100, tesonep(a)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

Jan. 22, 2020

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

by tesonep＠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 <pierce(a)samadhiweb.com> 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. tesonep(a)gmail.com

Jan. 22, 2020

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

by 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

Jan. 22, 2020

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

by ponyatov

Good day Is it a variant to implement an embeddable Little Smalltalk-like engine that does not use bytecode but uses LLVM JIT for direct machine code compilation? Or maybe can we use a less aggressive approach with the same embedded engine which interprets bytecode? -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 22, 2020