- Pharo-users - lists.pharo.org

keyboard shortcut for switching from "instance side" to "class side"

by Steve Quezadas

Does anyone know of a keyboard shortcut in pharo that switches from the method selectors in the "class side" to the "instance side"? I can't seem to find anything by browsing google. Ctrl-h seems to be an undocumented keystroke command to switch to "heirchy list" when the object in the browser is selected. So I would imagine there would also be something to switch to the class side/instance side. - Steve

Oct. 8, 2019

Re: [Pharo-users] Pharo launcher

by Christophe Demarey

Hi Ilker, It looks like you got the same issue as https://github.com/pharo-project/pharo-launcher/issues/349 If you do not run Pharo Launcher from cmd line or unzip is not in the path, it should works fine (waiting for a proper fix). Please try to delete corrupted VMs (you can use Pharo Launcher VM Manager) and try again. Thanks for the report, Christophe > Le 8 oct. 2019 Ã 15:35, ilker Ã¶zcan <ilkozcan(a)gmail.com> a Ã©crit : > > When i tried to install pharo 7 and 8 with the launcher on windows 10 there happened a message which says windows can not run 16 bit program.. > > It seems pharo.exe seems to be 16 bit ( i installed 64bit)..anyone with such a problem and any idea how i can solve this? Thanks all..

Oct. 8, 2019

Re: [Pharo-users] Pharo and new MacOS Catalina

by James Foster

> On Oct 8, 2019, at 5:24 AM, Kasper Ãsterbye <kasper.osterbye(a)gmail.com> wrote: > > Cheers, > > Have there been any problems with running Pharo on the new MacOS Catelina (10.15)? macOS Catalina (10.15) finally makes good on the promise to disable 32-bit applications. So Iâm no longer able to run the Pharo Mooc. James

Oct. 8, 2019

Re: [Pharo-users] voyage mongo and transactionality

by James Foster

> On Oct 8, 2019, at 3:05 AM, Jonathan van Alteren <jvalteren(a)objectguild.com> wrote: > > We've encountered an issue where a user makes changes to an agenda, but does not click the Save button. Instead, the user closes the browser or uses the navigation to go to a different part of the application. When navigating back to the original agenda, the changes made previously (e.g. items added) are still being displayed, even though they were never explicitly saved. Here is what I donât understand: how did the change get from the userâs client agent (browser) to the server? If you make a change to a field in a form and then close the browser, who sent the change to the server? If you show the save domain value in a different location, with a dynamically-generated id and name (so it isnât cached in the browser), or written to the Pharo Transcript, does the value still change? That is, are you sure that the change is in the reflected in the Smalltalk image and not just somehow cached in the browser? James

Oct. 8, 2019

Pharo launcher

by ilker Ã¶zcan

When i tried to install pharo 7 and 8 with the launcher on windows 10 there happened a message which says windows can not run 16 bit program.. It seems pharo.exe seems to be 16 bit ( i installed 64bit)..anyone with such a problem and any idea how i can solve this? Thanks all..

Oct. 8, 2019

Pharo and new MacOS Catalina

by Kasper Ãsterbye

Cheers, Have there been any problems with running Pharo on the new MacOS Catelina (10.15)?

Oct. 8, 2019

Re: [Pharo-users] voyage mongo and transactionality

by Esteban Lorenzano

Hi, That looks a lot more like a Seaside mishandling than a problem with Voyage itself. > On 8 Oct 2019, at 12:05, Jonathan van Alteren <jvalteren(a)objectguild.com> wrote: > > Hello all, > > We are having some issues with using Voyage/Mongo for a customer project that I'd like to get your feedback on. > > The customer application is a form based business web application using Seaside with object persistence using Voyage with MongoDB on Pharo 7.0. The application is deployed on a dedicated Linux production server running MongoDB version 4.2. > > The application is used to manage meeting agendas and minutes. After opening the agenda view of a future meeting, the user can add an item to the agenda by clicking a button. This calls an item editor component which answers when a Save or Cancel button is clicked. The agenda view component itself also has a Save button, which performs a Voyage save of the object aggregate (agenda + items). > > We've encountered an issue where a user makes changes to an agenda, but does not click the Save button. Instead, the user closes the browser or uses the navigation to go to a different part of the application. When navigating back to the original agenda, the changes made previously (e.g. items added) are still being displayed, even though they were never explicitly saved. > > It does not matter if we select the agenda aggregate object instance using Voyage or access it in a different way. Changes to the state of the object are retained, even though a Voyage save was never sent to the agenda instance. The cause seems to be that the Voyage repository caches the object instance and thus on select, it returns an object that is in a different state than how it was persisted. > > This all seems to come down to object transactionality. > > We have a need to 'cancel' changes made to an object instance. Before working with Pharo/Smalltalk in a non-image based environment, I was used to do this by retrieving the original object from persistence again. This also allowed for a convenient way to detect changes to an object's state, which we are missing at the moment too. In Voyage, new objects are just persisted (hence they enter the cache) once you do the first âsaveâ. Retrieved objects are indeed in the cache, and since there is just one copy for Pharo instance, if you do an update of a property (even if you do not save), the cached instance will have the new attribute value, since there is no in-memory transaction handling in Voyage. Which means: you need to handle it by your self. One solution is to work on a copy and on âsaveâ flush the changes before (it is easy to develop methods to automatise this). Well, something like that :) > > We know that moving to GemStone can help us with these issues, but our current planning of customer projects does not allow us to do this within the next 3 months. And we really need to find a way to tackle these issues . Well, not really, you will still need to copy modified values, retrieve new and apply your changes. Of course if you want to discard possible in-memory changes, yes, you can cancel the transaction in gemstoneâ¦ and you can also re-read the object in Voyage (no special api for that, even if we could add itâ¦ you need to re-execute a query for it). Esteban > > > Your feedback is greatly appreciated! > > > > Kind regards, > > > Jonathan van Alteren > > Founding Member | Object Guild > jvalteren(a)objectguild.com >

Oct. 8, 2019

Re: [Pharo-users] voyage mongo and transactionality

by Norbert Hartl

Hi, > Am 08.10.2019 um 12:05 schrieb Jonathan van Alteren <jvalteren(a)objectguild.com>: > > Hello all, > > We are having some issues with using Voyage/Mongo for a customer project that I'd like to get your feedback on. > > The customer application is a form based business web application using Seaside with object persistence using Voyage with MongoDB on Pharo 7.0. The application is deployed on a dedicated Linux production server running MongoDB version 4.2. > > The application is used to manage meeting agendas and minutes. After opening the agenda view of a future meeting, the user can add an item to the agenda by clicking a button. This calls an item editor component which answers when a Save or Cancel button is clicked. The agenda view component itself also has a Save button, which performs a Voyage save of the object aggregate (agenda + items). > > We've encountered an issue where a user makes changes to an agenda, but does not click the Save button. Instead, the user closes the browser or uses the navigation to go to a different part of the application. When navigating back to the original agenda, the changes made previously (e.g. items added) are still being displayed, even though they were never explicitly saved. > > It does not matter if we select the agenda aggregate object instance using Voyage or access it in a different way. Changes to the state of the object are retained, even though a Voyage save was never sent to the agenda instance. The cause seems to be that the Voyage repository caches the object instance and thus on select, it returns an object that is in a different state than how it was persisted. > > This all seems to come down to object transactionality. > > We have a need to 'cancel' changes made to an object instance. Before working with Pharo/Smalltalk in a non-image based environment, I was used to do this by retrieving the original object from persistence again. This also allowed for a convenient way to detect changes to an object's state, which we are missing at the moment too. > > We know that moving to GemStone can help us with these issues, but our current planning of customer projects does not allow us to do this within the next 3 months. And we really need to find a way to tackle these issues . > > > Your feedback is greatly appreciated! > this is none to be confusing to a lot of people. If you map a memory object graph to a database there are no intrinsic points of transactions unless you put them into your application model. Gemstone or any transaction based handling wonât help you if your use case is not as coarse grained as discarding all modified data and not just some. Or you need to hop into nested transactions which are supported by Gemstone IMHO but there is rules to care about, too, if you want to use them. Regarding your application you modify data and this is kept. The cache in mongo is a weak dictionary. This means that if you get the object with the changes a second time it means these objects are referenced somewhere. Seaside sessions seems to be the obvious thing here. If you have a reachable object (e.g. server singleton -> handler -> seaside -> seaside session -> business object) then mongo keeps the object in its cache because it needs to be able to establish identity on further queries. Ein emoving all the changes from an object you keep in memory wouldnât be really good if the persistence layer would do it. The problem is obvious but the solution is not. We could make the cache session or request based which would circumvent the problem. But if an object would be attached to something outside the session/request which you cannot forbid it causes real problems like multiple copies to an identical object. I donât know what you mean with object transactionality because it makes no sense in my head. But you have basically two approaches to solve the problem. If you would use magritte you would have it at hand. There each UI component gets just a memento of the business object for modification. You need to commit the UI component in order to modify the business object. So you can commit on user interaction and separately on persistence which allows a huge set of use cases. The other one Iâm working on since a while is a proper modification tracking. In this you change the objects directly but have a registry with the dirty objects which you can act upon. I have a sample modification tracker that uses readOnly object write barrier for objects. On write attempt it registers the object and the write operation as command pattern. You can undo modifications of a single object where all commmands are undone on that object. Or you abort all modifications at once. It is basically working but has the problems on concurrent access. As the mongo cache is image wide two concurrent requests interfere with each other. So you can see that the problem is not that easy to solve. TL;DR a memento approach might your best and cleanest option right now. Norbert > > Kind regards, > > > Jonathan van Alteren > > Founding Member | Object Guild > jvalteren(a)objectguild.com >

Oct. 8, 2019

voyage mongo and transactionality

by Jonathan van Alteren

Hello all, We are having some issues with using Voyage/Mongo for a customer project that I'd like to get your feedback on. The customer application is a form based business web application using Seaside with object persistence using Voyage with MongoDBÂ on Pharo 7.0. The application is deployed on a dedicated Linux production server running MongoDB version 4.2. The application is used to manage meeting agendas and minutes. After opening the agenda view of a future meeting, the user can add an item to the agenda by clicking a button. This calls an item editor component which answers when a Save or Cancel button is clicked. The agenda view component itself also has a Save button, which performs a Voyage save of the object aggregate (agenda + items). We've encountered an issue where a user makes changes to an agenda, but does not click the Save button. Instead, the user closes the browser or uses the navigation to go to a different part of the application. When navigating back to the original agenda, the changes made previously (e.g. items added) are still being displayed, even though they were never explicitly saved. It does not matter if we select the agenda aggregate object instance using Voyage or access it in a different way. Changes to the state of the object are retained, even though a Voyage save was never sent to the agenda instance. The cause seems to be that the Voyage repository caches the object instance and thus on select, it returns an object that is in a different state than how it was persisted. This all seems to come down to object transactionality. We have a need to 'cancel' changes made to an object instance. Before working with Pharo/Smalltalk in a non-image based environment, I was used to do this by retrieving the original object from persistence again. This also allowed for a convenient way to detect changes to an object's state, which we are missing at the moment too. We know that moving to GemStone can help us with these issues, but our current planning of customer projects does not allow us to do this within the next 3 months. And we really need to find a way to tackle these issues . Your feedback is greatly appreciated! Kind regards, Jonathan van Alteren Founding Member | Object Guild jvalteren(a)objectguild.com

Oct. 8, 2019

Re: How to install stripe library on Pharo 7 64bit ?

by jmathews

Hi Paul, Thanks for the update. I tried your new code and it went futher than last time. However the debugger shows up during cleanup and the entire image hangs. I've attached a screenshot. I also retested this with a completely fresh image using pharolauncher with the same results. -James <http://forum.world.st/file/t372299/stripe_install_on_Pharo_7.png> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 7, 2019