December 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] From IRC: is glorp dead?

by Sven Van Caekenberghe

> On 07 Dec 2014, at 19:21, Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <assargaddon(a)gmail.com> wrote: > > Since this is a recurring question, I would be super if you could write a short article about your experiences. > > It's possible, but what exactly means "article"? > More specifically: where such an article should be posted to? It can be anything, a blog post too, anywhere you like. What I've used it just Markdown in GitHub which is very technical (https://github.com/svenvc/docs) Medium which is more like a normal publication and it looks very good (https://medium.com/@svenvc) as well as Pharo Pillar documentation (http://stfx.eu/EnterprisePharo/Zinc-Encoding-Meta/ - https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf…) But really anything you like or are comfortable with. > 2014-12-07 20:49 GMT+03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 07 Dec 2014, at 17:59, Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <assargaddon(a)gmail.com> wrote: > > > > GLORP-based applications is main source of income for me for last several yers. It works just now. And it definetely works in Ubuntu x64, if it's important. And also works fine in Windows. > > Yes, I know, but sometimes it is a bit difficult to set things up, giving all the different platforms. > > Since this is a recurring question, I would be super if you could write a short article about your experiences. > > Another simple Glorp introduction is https://medium.com/@svenvc/reddit-st-in-10-cool-pharo-classes-1b5327ca0740 > > > 2014-12-07 18:31 GMT+03:00 Brad <bsselfridge(a)gmail.com>: > > No, it's not dead, just pretty sleepy. I've got it working with MySQL on an Ubuntu 14.04 32bit OS, but not yet on a 64bit OS. > > > > Once I get my 64bit OS working, I'm going to work on getting Glorp/DBXTalk working for real business activity. > > > > Look here for some resources http://dbxtalk.smallworks.eu > > > > Brad Selfridge > > 913-269-2385 > > > > > On Dec 7, 2014, at 8:25 AM, Max Leske <maxleske(a)gmail.com> wrote: > > > > > > From the IRC: > > > > > > LudicrousMango: Hi can anyone tell me is Glorp dead? I was trying to evaluate pharo as a replacement for an existing rails project, but I can't even find a way of connecting to my postgresql database. > > > LudicrousMango: can someone help point me in the right direction. The Enterprise book leaves the setup part of glorp blank. > > > LudicrousMango: and the glorp.org site has expired > > > maxleske: LudicrousMango: good question. Iâll forward it to the dev mailing list > > > > > > > > > Cheers, > > > Max > > > > > > >

Dec. 7, 2014

Re: [Pharo-dev] Repeatable VM crash

by Eliot Miranda

Hi Mariano, On Dec 7, 2014, at 10:21 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Sun, Dec 7, 2014 at 3:09 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> Hi Hilaire, >> >> >> On Dec 7, 2014, at 12:35 AM, Hilaire <hilaire(a)drgeo.eu> wrote: >> >> > I download this one >> > http://www.mirandabanda.org/files/Cog/VM/VM.r3164/coglinux-14.48.3164.tgz >> > >> > and the crash is still there. Attached crash dump. >> >> different bugs. The 3164 VMs fix a 32-bit Spur bug. Your image is showing a bug in Cog that looks to be to do with the decompression primitive. I haven't had time to look at it deeply yet but can see it and should be able to fix it soon. > > You mean GZip stuff? Because I have found a similar issue years ago: http://forum.world.st/Re-Pharo-project-GZipWriteStream-crashing-my-VM-when-… No. That bug got fixed recently. This is a bug in the custom huffman-ciding bitmap decompression routine (selector begins with "decompress") that's compiled to a primitive. > >> >> > >> > Thanks >> > >> > Hilaire >> > >> > Le 06/12/2014 22:57, Eliot Miranda a Ã©crit : >> >> Hi Esteban, >> >> >> >> plausibly the fix to the latest VM might fix your crash. You might >> >> test? Fingers crossed. >> >> >> >> On Fri, Dec 5, 2014 at 11:26 PM, Esteban Lorenzano <estebanlm(a)gmail.com >> >> <mailto:estebanlm@gmail.com>> wrote: >> >> >> >> yes, but the first step is to be sure you have the latest vm version :) >> >> >> >> Esteban >> > >> > >> > -- >> > Dr. Geo - http://drgeo.eu >> > iStoa - http://istoa.drgeo.eu >> > <crash.dmp> > > > > -- > Mariano > http://marianopeck.wordpress.com

Dec. 7, 2014

Re: [Pharo-dev] Monticello and Fuel

by Eliot Miranda

Hi Max, oops, I was being dense... On Dec 7, 2014, at 5:14 AM, Max Leske <maxleske(a)gmail.com> wrote: > >> On 07 Dec 2014, at 04:19, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi Max, > > Hi Eliot, > >> >> On Sat, Dec 6, 2014 at 1:43 AM, Max Leske <maxleske(a)gmail.com> wrote: >>> >>>> On 06 Dec 2014, at 04:37, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>> >>>> >>>> >>>> On Thu, Dec 4, 2014 at 11:35 PM, Max Leske <maxleske(a)gmail.com> wrote: >>>>> >>>>> > On 05 Dec 2014, at 08:02, Norbert Hartl <norbert(a)hartl.name> wrote: >>>>> > >>>>> > >>>>> > >>>>> > >>>>> >> Am 04.12.2014 um 23:31 schrieb Thierry Goubier <thierry.goubier(a)gmail.com>: >>>>> >> >>>>> >> Hi all, >>>>> >> >>>>> >> I'm just wondering. >>>>> >> >>>>> >> Would it work to have a package format based on Fuel? >>>>> >> >>>>> > I doubt it would work cross platform. I don't know how fuel serializes WideString, LargePositiveInteger, BoxedFloat64. These differ between smalltalk platforms. The source as string solves that. Strings are written as unicode string and numbers as certain number format etc. >>>>> >>>>> True. Cross dialect loading isnât something we encourage to do with Fuel. >>>>> >>>>> @Thierry >>>>> You said something about partial loading: that will never be possible with Fuel because of its pickle format. To select any partial graph you have to first read the entire file and rebuild the graph first (ok, you donât strictly have to build the graph but you still need to read the entire file). >>>> >>>> Hi Max, you misunderstand what partial loading means in this context. I designed and implemented partial loading for the Parcel system in VW, and Fuel is essentially a clean reimplementation of parcels. The idea is that one does indeed read the entire object graph, but then only the parts of the graph that mate with the current class hierarchy are installed, and the bits that don't fit are stored for later. Why? So that a component can define extensions on classes in components that may not be present. Why? So that one can maintain a single logical component in a single package instead of decomposing it into independently loadable fragments. >>> >>> Makes sense. Itâs just that I often get asked if it is possible to read / update only parts of a Fuel file, so I wanted to make it clear that that canât work. >> >> Right, good point. But is there a use case? For example, in effect is there a difference between being able to patch a part of a Fuel file and loading that file into an image (possibly automatically), patching the object graph and saving a new version? > > Yes, performance seems to be the main use case. Fuel files of hundreds of MB take a long time to load and save, even if you only change a single string. One instance where this is relevant is the Moose model. They currently use .mse files, which use a textual representation (if Iâm not mistaken). Usman asked me if Fuel were an option, especially for updating only parts of the model. Ah ok. Then yes, I suspect Fuel will be faster, but that patching is more complex because it can't be done in a text editor. How do they edit the .mse file? IME text editors suck on large files. What are the relative frequencies of writing, reading and editing these files? >>>> Lets take an example like Fuel itself. This may have specialised marshalling and unmarshalling extensions defined on may classes, some of which may be to do with the GUI. If we have partial loading we can load Fuel into a headless image. The extensions on the GUI classes will simply not be installed, *until* we load the GUI. Hence Fuel does not have to be decomposed every time we factor the system into subcomponents. Without partial loading Fuel must be decomposed into a series of fragments so that it can load that part that fits into the headless base, and we have to manage teh dependency to ensure the fragment that loads against the GUI is loaded when the GUI is loaded. Worse still, if we cut the GUI into two (e.g. development vs deployment tools) we have to visit the Fuel GUI component (and potentially many other component) and decompose it into two pieces. In practice this is extremely costly to maintain, verging on chaos. With partial loading things are simple. >>>> >>>> Perhaps I should have called it partial installation, but you get the idea. >>> >>> Thanks for the explanation. >>> >>>> >>>>> >>>>> > >>>>> > Norbert >>>>> > >>>>> >> Would that make loading faster? >>>>> >> >>>>> >> Does it already exist? >>>>> >> >>>>> >> Thanks, >>>>> >> >>>>> >> Thierry >>>>> > >>>> >>>> >>>> >>>> -- >>>> best, >>>> Eliot >> >> >> >> -- >> best, >> Eliot >

Dec. 7, 2014

Re: [Pharo-dev] Repeatable VM crash

by Mariano Martinez Peck

On Sun, Dec 7, 2014 at 3:09 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Hilaire, > > > On Dec 7, 2014, at 12:35 AM, Hilaire <hilaire(a)drgeo.eu> wrote: > > > I download this one > > > http://www.mirandabanda.org/files/Cog/VM/VM.r3164/coglinux-14.48.3164.tgz > > > > and the crash is still there. Attached crash dump. > > different bugs. The 3164 VMs fix a 32-bit Spur bug. Your image is > showing a bug in Cog that looks to be to do with the decompression > primitive. I haven't had time to look at it deeply yet but can see it and > should be able to fix it soon. > You mean GZip stuff? Because I have found a similar issue years ago: http://forum.world.st/Re-Pharo-project-GZipWriteStream-crashing-my-VM-when-… > > > > > Thanks > > > > Hilaire > > > > Le 06/12/2014 22:57, Eliot Miranda a Ã©crit : > >> Hi Esteban, > >> > >> plausibly the fix to the latest VM might fix your crash. You might > >> test? Fingers crossed. > >> > >> On Fri, Dec 5, 2014 at 11:26 PM, Esteban Lorenzano <estebanlm(a)gmail.com > >> <mailto:estebanlm@gmail.com>> wrote: > >> > >> yes, but the first step is to be sure you have the latest vm version > :) > >> > >> Esteban > > > > > > -- > > Dr. Geo - http://drgeo.eu > > iStoa - http://istoa.drgeo.eu > > <crash.dmp> > > -- Mariano http://marianopeck.wordpress.com

Dec. 7, 2014

Re: [Pharo-dev] From IRC: is glorp dead?

by Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾

> > Since this is a recurring question, I would be super if you could write a > short article about your experiences. It's possible, but what exactly means "article"? More specifically: where such an article should be posted to? 2014-12-07 20:49 GMT+03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 07 Dec 2014, at 17:59, Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <assargaddon(a)gmail.com> wrote: > > > > GLORP-based applications is main source of income for me for last > several yers. It works just now. And it definetely works in Ubuntu x64, if > it's important. And also works fine in Windows. > > Yes, I know, but sometimes it is a bit difficult to set things up, giving > all the different platforms. > > Since this is a recurring question, I would be super if you could write a > short article about your experiences. > > Another simple Glorp introduction is > https://medium.com/@svenvc/reddit-st-in-10-cool-pharo-classes-1b5327ca0740 > > > 2014-12-07 18:31 GMT+03:00 Brad <bsselfridge(a)gmail.com>: > > No, it's not dead, just pretty sleepy. I've got it working with MySQL on > an Ubuntu 14.04 32bit OS, but not yet on a 64bit OS. > > > > Once I get my 64bit OS working, I'm going to work on getting > Glorp/DBXTalk working for real business activity. > > > > Look here for some resources http://dbxtalk.smallworks.eu > > > > Brad Selfridge > > 913-269-2385 > > > > > On Dec 7, 2014, at 8:25 AM, Max Leske <maxleske(a)gmail.com> wrote: > > > > > > From the IRC: > > > > > > LudicrousMango: Hi can anyone tell me is Glorp dead? I was trying to > evaluate pharo as a replacement for an existing rails project, but I can't > even find a way of connecting to my postgresql database. > > > LudicrousMango: can someone help point me in the right direction. The > Enterprise book leaves the setup part of glorp blank. > > > LudicrousMango: and the glorp.org site has expired > > > maxleske: LudicrousMango: good question. Iâll forward it to the dev > mailing list > > > > > > > > > Cheers, > > > Max > > > > > > >

Dec. 7, 2014

Re: [Pharo-dev] Monticello and Fuel

by Eliot Miranda

Hi Max, On Dec 7, 2014, at 5:14 AM, Max Leske <maxleske(a)gmail.com> wrote: > >> On 07 Dec 2014, at 04:19, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi Max, > > Hi Eliot, > >> >> On Sat, Dec 6, 2014 at 1:43 AM, Max Leske <maxleske(a)gmail.com> wrote: >>> >>>> On 06 Dec 2014, at 04:37, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>> >>>> >>>> >>>> On Thu, Dec 4, 2014 at 11:35 PM, Max Leske <maxleske(a)gmail.com> wrote: >>>>> >>>>> > On 05 Dec 2014, at 08:02, Norbert Hartl <norbert(a)hartl.name> wrote: >>>>> > >>>>> > >>>>> > >>>>> > >>>>> >> Am 04.12.2014 um 23:31 schrieb Thierry Goubier <thierry.goubier(a)gmail.com>: >>>>> >> >>>>> >> Hi all, >>>>> >> >>>>> >> I'm just wondering. >>>>> >> >>>>> >> Would it work to have a package format based on Fuel? >>>>> >> >>>>> > I doubt it would work cross platform. I don't know how fuel serializes WideString, LargePositiveInteger, BoxedFloat64. These differ between smalltalk platforms. The source as string solves that. Strings are written as unicode string and numbers as certain number format etc. >>>>> >>>>> True. Cross dialect loading isnât something we encourage to do with Fuel. >>>>> >>>>> @Thierry >>>>> You said something about partial loading: that will never be possible with Fuel because of its pickle format. To select any partial graph you have to first read the entire file and rebuild the graph first (ok, you donât strictly have to build the graph but you still need to read the entire file). >>>> >>>> Hi Max, you misunderstand what partial loading means in this context. I designed and implemented partial loading for the Parcel system in VW, and Fuel is essentially a clean reimplementation of parcels. The idea is that one does indeed read the entire object graph, but then only the parts of the graph that mate with the current class hierarchy are installed, and the bits that don't fit are stored for later. Why? So that a component can define extensions on classes in components that may not be present. Why? So that one can maintain a single logical component in a single package instead of decomposing it into independently loadable fragments. >>> >>> Makes sense. Itâs just that I often get asked if it is possible to read / update only parts of a Fuel file, so I wanted to make it clear that that canât work. >> >> Right, good point. But is there a use case? For example, in effect is there a difference between being able to patch a part of a Fuel file and loading that file into an image (possibly automatically), patching the object graph and saving a new version? > > Yes, performance seems to be the main use case. Fuel files of hundreds of MB take a long time to load and save, even if you only change a single string. One instance where this is relevant is the Moose model. They currently use .mse files, which use a textual representation (if Iâm not mistaken). Usman asked me if Fuel were an option, especially for updating only parts of the model. Ok, but how could patching the file be much faster? The file has to be parsed into something; why not the objects themselves? To me loading, editing and red acing is patching and done as fast as Fuel can do things. Depending on syntax you may be able to scan for a string and replace using eg the sed stream editor. But that'll only work for simple data like strings. If you really need this to be faster have you considered - decomposing the Moose model into smaller individual components? - keeping the moose model to be saved in an image (possibly live running in a server) and patching the model in the image and saving it - using Spur [ ;-) ]. The Pharos tests now run and it should be significantly faster, at least at loading > >> >>>> Lets take an example like Fuel itself. This may have specialised marshalling and unmarshalling extensions defined on may classes, some of which may be to do with the GUI. If we have partial loading we can load Fuel into a headless image. The extensions on the GUI classes will simply not be installed, *until* we load the GUI. Hence Fuel does not have to be decomposed every time we factor the system into subcomponents. Without partial loading Fuel must be decomposed into a series of fragments so that it can load that part that fits into the headless base, and we have to manage teh dependency to ensure the fragment that loads against the GUI is loaded when the GUI is loaded. Worse still, if we cut the GUI into two (e.g. development vs deployment tools) we have to visit the Fuel GUI component (and potentially many other component) and decompose it into two pieces. In practice this is extremely costly to maintain, verging on chaos. With partial loading things are simple. >>>> >>>> Perhaps I should have called it partial installation, but you get the idea. >>> >>> Thanks for the explanation. >>> >>>> >>>>> >>>>> > >>>>> > Norbert >>>>> > >>>>> >> Would that make loading faster? >>>>> >> >>>>> >> Does it already exist? >>>>> >> >>>>> >> Thanks, >>>>> >> >>>>> >> Thierry >>>>> > >>>> >>>> >>>> >>>> -- >>>> best, >>>> Eliot >> >> >> >> -- >> best, >> Eliot >

Dec. 7, 2014

Re: [Pharo-dev] Repeatable VM crash

by Eliot Miranda

On Dec 7, 2014, at 3:33 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > yes, tests now are finishing without crash! Cool, good. > > https://ci.inria.fr/pharo/view/4.0-VM-Spur/job/Pharo-spur32-tests > > now that we are ready yet, but almost there :) > > Esteban > >> On 06 Dec 2014, at 22:57, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi Esteban, >> >> plausibly the fix to the latest VM might fix your crash. You might test? Fingers crossed. >> >> On Fri, Dec 5, 2014 at 11:26 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> yes, but the first step is to be sure you have the latest vm version :) >>> >>> Esteban >>> >>> >>>> On 05 Dec 2014, at 22:37, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>> >>>> Hi Hilaire, >>>> >>>> can you try and concoct an image that crashes from start-up without operator intervention? What I mean is that if the expression that crashes is the one you give then in a workspace evaluate >>>> >>>> Smalltalk snapshot: true andQuit: true. >>>> (CGDonator firstname: 'Eric' lastname: 'Dupont') = (CGParticipant firstname: 'Eric' lastname: 'Dupont') >>>> >>>> and then run the saved image. If it crashes then its really easy to debug because it will be repeatable. If one has to interact with the image debugging is much more difficult. >>>> >>>> On Fri, Dec 5, 2014 at 1:07 PM, Hilaire <hilaire(a)drgeo.eu> wrote: >>>>> Hi again, >>>>> >>>>> I must add it occurs from a test or when comparing something like this >>>>> in the Workspace: >>>>> >>>>> (CGDonator firstname: 'Eric' lastname: 'Dupont') = (CGParticipant >>>>> firstname: 'Eric' lastname: 'Dupont') >>>>> >>>>> I get a false returned value printed in the Workspace, then VM crash. >>>>> >>>>> Thanks >>>>> >>>>> Hilaire >>>>> >>>>> >>>>> Le 05/12/2014 21:35, Hilaire a Ã©crit : >>>>> > When playing with equality in a class hierarchy I have repeatable VM crash. >>>>> > It is today Pharo VM 3.9-7 from Jenkins and Pharo3. >>>>> > >>>>> > Am I using an out of date VM? >>>>> > >>>>> > Crashdump enclosed >>>>> > >>>>> > Hilaire >>>>> > >>>>> > >>>>> >>>>> >>>>> -- >>>>> Dr. Geo - http://drgeo.eu >>>>> iStoa - http://istoa.drgeo.eu >>>> >>>> >>>> >>>> -- >>>> best, >>>> Eliot >> >> >> >> -- >> best, >> Eliot >

Dec. 7, 2014

Re: [Pharo-dev] Repeatable VM crash

by Eliot Miranda

Hi Hilaire, On Dec 7, 2014, at 12:35 AM, Hilaire <hilaire(a)drgeo.eu> wrote: > I download this one > http://www.mirandabanda.org/files/Cog/VM/VM.r3164/coglinux-14.48.3164.tgz > > and the crash is still there. Attached crash dump. different bugs. The 3164 VMs fix a 32-bit Spur bug. Your image is showing a bug in Cog that looks to be to do with the decompression primitive. I haven't had time to look at it deeply yet but can see it and should be able to fix it soon. > > Thanks > > Hilaire > > Le 06/12/2014 22:57, Eliot Miranda a Ã©crit : >> Hi Esteban, >> >> plausibly the fix to the latest VM might fix your crash. You might >> test? Fingers crossed. >> >> On Fri, Dec 5, 2014 at 11:26 PM, Esteban Lorenzano <estebanlm(a)gmail.com >> <mailto:estebanlm@gmail.com>> wrote: >> >> yes, but the first step is to be sure you have the latest vm version :) >> >> Esteban > > > -- > Dr. Geo - http://drgeo.eu > iStoa - http://istoa.drgeo.eu > <crash.dmp>

Dec. 7, 2014

Re: [Pharo-dev] [Moose-dev] [ann] gtspotter: a moldable interface for spotting objects

by Tudor Girba

Hi Sven, Thanks for the kind words. Indeed, having the current selection is one of the things we should keep in mind. For that we need to go to the next step and integrate the interface in the overall environment. This will certainly come. Cheers, Doru On Sun, Dec 7, 2014 at 6:57 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 07 Dec 2014, at 14:14, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > Alex Syrel, Andrei Chis and I are happy to announce a new addition to > the Glamorous Toolkit: > > GTSpotter, a novel interface for spotting objects. > > Excellent work, all around. Congratulations to the team. Thank you for > pushing things like this, for thinking differently. > > Yes, I want this in Pharo 4 too, ASAP (especially since the main shortcut > is different from the old one, cmd+Enter vs. shift+Enter). > > The presentation is again very well done too: excellent article, super > movie. You are putting the bar very high for the rest of us ;-) > > A suggestion/idea: would it be possible to take the current selection > anywhere and feed it into Spotter ? That way there would be very good way > to make it replace all the other shortcuts: you would get implementers, > senders, references almost for free. > > Sven > > > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 7, 2014

Re: [Pharo-dev] [Moose-dev] [ann] gtspotter: a moldable interface for spotting objects

by Sven Van Caekenberghe

> On 07 Dec 2014, at 14:14, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Alex Syrel, Andrei Chis and I are happy to announce a new addition to the Glamorous Toolkit: > GTSpotter, a novel interface for spotting objects. Excellent work, all around. Congratulations to the team. Thank you for pushing things like this, for thinking differently. Yes, I want this in Pharo 4 too, ASAP (especially since the main shortcut is different from the old one, cmd+Enter vs. shift+Enter). The presentation is again very well done too: excellent article, super movie. You are putting the bar very high for the rest of us ;-) A suggestion/idea: would it be possible to take the current selection anywhere and feed it into Spotter ? That way there would be very good way to make it replace all the other shortcuts: you would get implementers, senders, references almost for free. Sven

Dec. 7, 2014