[Glass] Basic questions regarding GemBuilder for Smalltalk, GemTools, and tODE
Locked
12
12
[Glass] Basic questions regarding GemBuilder for Smalltalk, GemTools, and tODE
 
|
Hi guys,
I am evaluating GemStone for a client and I want to give it a try. I have a very high level idea of GemStone but I never use it for real. The application I may need to run in GemStone is a Seaside app 3.0 + Magritte3.
Something that confuses me a lot if all these pieces that seem somehow related: GemBuilder for Smalltalk, GemTools, and tODE. And I have a few questions related to these. Thanks in advance for any help you can give me.
From what I understand, I do need a kind of "GemBuilder for Smalltalk" in order to connect my client Smalltalk (Pharo in my case) to GemStone. But there isn't any GemBuilder for Pharo (only VW and VA). I also thought part of GemBuilder was to map certain kernel classes of the client language to GemStone, to retrieve objects from GemStone into my smalltalk client vm..etc. So..I guess GemTools is a subset of an equivalent "GemBuilder for Pharo"? What is its relation to the GemBuilder? From what I understand, GemTools offers me some tools to connect to a GemStone server, load code, execute some code on the server, etc etc etc. I think I can do more or less the same with Topaz as well. That means that GemBuilder is optional and I could use Topaz only. If I use Topaz directly, it means that I don't need any GemBuilder at all for Pharo? If true, how then it happens that "mapping of certain kernel classes" that I read somewhere? in other word, why would I not need a GemBuilder for Pharo but do need it for VW and VA? Just because there is no UI and all we have is seaside running? And if I run Seaside in VW then I don't need GemBuilder for VW?
If I don't need GemBuilder at all, how can I know which classes/methods of Pharo can I use and which ones I cannot? I noticed the GemTools is based on a very very old Pharo image. I guess this is not a very big problem because I would use that image only to load my code into GemStone and maybe for other small issues. Still, I will continue developing my app in Pharo 2.0 and I will keep having my ConfigurationOfXXX with the proper load for GemStone. Right?
Anyway...now how is tODE related to GemTools? What does tODE help me regarding GemStone? Can I use it already or should I still with GemTools/Topaz for the moment? I searched in Gemtalk Systems and I found nothing.
Thank you very much! Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
|
|
Mariano,
I guess you just nailed down a list of questions that many others have about Gemstone/S and GLASS. While I think I know some of the answers to your questions, I hope for someone with more experience to answer them. Some of the questions are also open for me ;-) So thanks for bringing these up and thanks in advance for qualified answers ;-) Joachim Am 30.09.13 22:48, schrieb Mariano Martinez Peck:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Basic questions regarding GemBuilder for Smalltalk, GemTools, and tODE
|
|
In reply to this post by Mariano Martinez Peck
On 09/30/2013 01:48 PM, Mariano Martinez Peck wrote:
> Hi guys, > > I am evaluating GemStone for a client and I want to give it a try. I > have a very high level idea of GemStone but I never use it for real. The > application I may need to run in GemStone is a Seaside app 3.0 + Magritte3. > > Something that confuses me a lot if all these pieces that seem somehow > related: GemBuilder for Smalltalk, GemTools, and tODE. And I have a few > questions related to these. Thanks in advance for any help you can give me. Hi Mariano, I'm glad you're wanting to try out GemStone/S! Some short answers, for now: The thing that GemBuilder for Smalltalk (GBS), GemTools, tODE, and Topaz all have in common is that they are all development environments for developing GemStone code. Each has its advantages and disadvantages. GBS *also* allows the creation of distributed client/server Smalltalk applications, with the client being VW or VA Smalltalk and the server being GemStone Smalltalk. Its development tools are slanted towards that task, though they also work for developing and debugging standalone GemStone applications. If you're developing a Seaside app that will run in GemStone/S, you can use whichever development environment seems best for the task at hand -- tODE, GemTools, or Topaz. I know I didn't get *all* of your questions answered, but I hope that this helps you navigate the landscape. Regards, -Martin _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Basic questions regarding GemBuilder for Smalltalk, GemTools, and tODE
|
|
In reply to this post by Mariano Martinez Peck
>> Something that confuses me a lot if all these pieces that
seem somehow related: GemBuilder for Smalltalk, GemTools, and tODE.
That's not surprising, when all is said and
done.
GemBuilder is the only truly licensed and supported
product - supported by GemTalk Systems - among those three. GemTools, tODE,
and Jade are the work of individual employees of GemTalk Systems but open
sourced to the community (at least some of them). Additionally, there is
Topaz, which one could consider the GemStone/S command-line interpreter,
definitely not an IDE.
One of the most important things in GBS is its
"traversal buffer" technology which allows seamless and high performance
replication of objects between the client and the server. This allows one to
have the same class defined on the server and on the client (VW or VA) which
some subset of the functionality defined in the server and some in the client,
with the data being replicated between the two as the client and server
processes interact.
Topaz, GemTools, and Jade all allow one to develop
against a server. The latter two provide a GUI similar to the familiar and
mostly well-loved Smalltalk browsers.
>> I also thought part of GemBuilder was to map certain
kernel classes of the client language to GemStone
Not
just certain kernel classes, but any classes you wish, including your
application classes. This is important if you want to have a rich client/server
application, not just a server app.
>> why would
I not need a GemBuilder for Pharo but do need it for VW and
VA?
It isn't that you don't need a GemBuilder for Pharo,
but that we do not have a commercial product for Pharo. Virtually all of our
paying customers have either VA or VW applications. GemBuilder is an elaborate
product, which requires considerable effort to port to a new environment and to
support.
>> how is tODE related to
GemTools?
I
think the answer to this question is "barely!". tODE is a fascinating approach
to an IDE, hosted in Pharo but with virtually all the work other than
presentation provided in the server. You should refer to Dale's various
conference talks for details on tODE. One of the most important things it
addresses is the difficulty in modifying or subclassing existing browser classes
to add capabilities. Over the years, I have had countless frustrations while
trying to avoid modifying vendor code but adding features. tODE "deconstructs"
the browser, in theory making this much easier to
accomplish.
I hope
this helps answer some of your questions, even if it fails to tell you what to
do. :-)
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Basic questions regarding GemBuilder for Smalltalk, GemTools, and tODE
|
|
Thank you all for your answers. It is now pretty clear to me the differences and what I need and don't need. Thanks. One last question regarding tODE...I do understand it provides some tools built on top on the web, and I have seen a few presentations from Dale. The thing is that I remember seeing some emails from Dale talking or relating tODE with GemTools. So...besides having an IDE on top on the web, does tODE provides or will provide some functionality of GemTools? I GUESS you may be able to run tODE directly on the seaside running in GemStone itself so it helps you browse the code etc. If we have a workspace...then I guess we are able to load our app code into GemStone and do what we want.. etc.. so maybe this is the thing? that running tODE in GemStone could give us the functionality we now have in GemTools?
Now that I have this thread already open ;) I wonder if someone has ever written some "port rules" or things to be aware when deploying to GemStone. I guess certain Pharo kernel classes/methods may not exist or answer something different, etc... And I think the answer would be around Grease? In other words, what I ask is the following: imagine (it is not the case unfortunately) I don't use any other library than seaside/magritte. What are the things that would make the port to gemstone complicated? Is there any list or conventions somewhere?
Thanks On Tue, Oct 1, 2013 at 3:55 AM, Richard Sargent <[hidden email]> wrote:
Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
|
|
Mariano,
We've been running a Seaside 3 / Magritte 3 app on GS for a while now. We develop in Pharo 1.4 (suppose that could be 2). The application works in Pharo 1.4, almost all tests run in Pharo 1.4. There are a few very small tests that we run in GemStone only, but to be honest I had to search for them now because I could not remember - so we rarely touch them. We then write the code to filetree and use filetree to load back into GS via topaz. The only thing we use GemTools for is to hunt for bugs. If we really can't understand why the app works in Pharo and not in GS, we use GemTools to set a breakpoint and figure out what's going on. Once we know, we exit GemTools and write code in Pharo. Sometimes we edit code using GemTools just to see how something will work if it is that specific to GS. Also, sometimes, it helps to inspect data objects which we only have in a GS DB. We do not even use GemTools to work on remote GS instances. We only use topaz for that. Topaz is good enough for most things. In 6 years, it happened about 2 times that we made a backup of the production DB, copy it local and then use GemTools to debug. I would not consider using a GBS based tool, I would just develop in Pharo, given that you know Pharo pretty well. GemTools is not workable as a development tool. And I can't imagine that tODE is. That is if you use refactoring tools, customise your image and run things like lint. Some more answers below: > that running tODE in GemStone could give us the > functionality we now have in GemTools? I think so. I think that the energy that would have to go into tODE to make it more than that would be enormous, but then I would be glad to hear otherwise. > Now that I have this thread already open ;) I wonder if someone has ever > written some "port rules" or things to be aware when deploying to GemStone. > I guess certain Pharo kernel classes/methods may not exist or answer > something different, etc... And I think the answer would be around Grease? > In other words, what I ask is the following: imagine (it is not the case > unfortunately) I don't use any other library than seaside/magritte. What are > the things that would make the port to gemstone complicated? Is there any > list or conventions somewhere? We've used Grease and have some stuff that we did before grease existed. And we've not been good at contributing stuff. Mainly because we get under pressure and then soon fall behind, sticking to older versions. Upgrading is costly. Not sure how to improve this situation. Having said this, we're willing to help and give anyone stuff we've done to make the port easier. It is not that onerous. Dale and others have done a lot; just to get Seaside into GS extended a lot of GS kernel classes to be Pharo / Seaside compatible. We have 2 Metacello configs. The one called "Runtime" loads all the Seaside / Magritte / Whatever tools we use from the community, with some differences between what we load into GS / Pharo. The other is our own project that is dependent on Runtime, also with small compatibility changes between the different environments. Please let me know where I can give you more info or code. Cheers Otto _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Basic questions regarding GemBuilder for Smalltalk, GemTools, and tODE
Administrator
|
In reply to this post by Mariano Martinez Peck
>> regarding tODE...I do understand it provides some tools built on top on the web Dale is the authority on tODE, but I don't think it has anything build on top of the web. There was an effort by someone else to port it to Amber Smalltalk, but I don't know the state of that.>> does tODE provides or will provide some functionality of GemTools? On Tue, Oct 1, 2013 at 6:11 AM, Mariano Martinez Peck <[hidden email]> wrote:
--
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Basic questions regarding GemBuilder for Smalltalk, GemTools, and tODE
|
|
In reply to this post by Mariano Martinez Peck
Hi Mariano,
Others have given good answers, but I'll offer my input as well! See http://programminggems.wordpress.com/2013/10/01/jade/ for a blog post and https://www.youtube.com/watch?v=dnRB5rBbkiI for a screencast showing how to load Seaside 3.0 and Magritte3 into GemStone/S 3.1.0.4. Also this gives a demo of Jade, a GemStone/S IDE for Microsoft Windows that has been in development and use for about 10 years and has good network performance. James On Sep 30, 2013, at 1:48 PM, Mariano Martinez Peck <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
|
|
In reply to this post by otto
Otto,
thanks a million for the insights you're providing here. I'd like to dig into a few questions regarding your development process. One thing that sounds scary to Gemstone wannabees (at least it does to me) is the big question of moving/extracting data to use on a separatte environment. Like getting a Customer's set of objects from the productioon system and moving it to a development/test machine to debug and find problems. If you have a big database with a few hundred customers' data, a whole db backup might not be a good option. How do you handle such scenarios with Gemstone? Do you write Smalltalk code to extract stuff from Gemstone as XML and move it into Pharo? What do you use as a persistence solution for such data? Just the image? XML files? Another scenario here is static data (report definitions etc.) that you have to move up from your development stage to a test stage and finally into the production environment. How do you transport this kind of data from your Pharo dev environment to a Gemstone test server and then to the production Gem? How do you test the side effects/behaviour of Gemstone transactions in your Pharo image? I mean, you should be able to play back/forth ok/cancel games and see if your control flow in Seaside is correct? Is there some kind of "Transaction emulator" for Pharo that gives you this? I know that Gemstone users always laugh about such questions, because they found a way to do all this? But as a wannabee, you look at all this stuff and just wonder... Joachim Am 01.10.13 17:28, schrieb Otto Behrens: > Mariano, > > We've been running a Seaside 3 / Magritte 3 app on GS for a while now. > > We develop in Pharo 1.4 (suppose that could be 2). The application > works in Pharo 1.4, almost all tests run in Pharo 1.4. There are a few > very small tests that we run in GemStone only, but to be honest I had > to search for them now because I could not remember - so we rarely > touch them. > > We then write the code to filetree and use filetree to load back into > GS via topaz. > > The only thing we use GemTools for is to hunt for bugs. If we really > can't understand why the app works in Pharo and not in GS, we use > GemTools to set a breakpoint and figure out what's going on. Once we > know, we exit GemTools and write code in Pharo. Sometimes we edit code > using GemTools just to see how something will work if it is that > specific to GS. Also, sometimes, it helps to inspect data objects > which we only have in a GS DB. > > We do not even use GemTools to work on remote GS instances. We only > use topaz for that. Topaz is good enough for most things. In 6 years, > it happened about 2 times that we made a backup of the production DB, > copy it local and then use GemTools to debug. > > I would not consider using a GBS based tool, I would just develop in > Pharo, given that you know Pharo pretty well. GemTools is not workable > as a development tool. And I can't imagine that tODE is. That is if > you use refactoring tools, customise your image and run things like > lint. > > Some more answers below: > >> that running tODE in GemStone could give us the >> functionality we now have in GemTools? > I think so. I think that the energy that would have to go into tODE to > make it more than that would be enormous, but then I would be glad to > hear otherwise. > >> Now that I have this thread already open ;) I wonder if someone has ever >> written some "port rules" or things to be aware when deploying to GemStone. >> I guess certain Pharo kernel classes/methods may not exist or answer >> something different, etc... And I think the answer would be around Grease? >> In other words, what I ask is the following: imagine (it is not the case >> unfortunately) I don't use any other library than seaside/magritte. What are >> the things that would make the port to gemstone complicated? Is there any >> list or conventions somewhere? > We've used Grease and have some stuff that we did before grease > existed. And we've not been good at contributing stuff. Mainly because > we get under pressure and then soon fall behind, sticking to older > versions. Upgrading is costly. Not sure how to improve this situation. > > Having said this, we're willing to help and give anyone stuff we've > done to make the port easier. It is not that onerous. Dale and others > have done a lot; just to get Seaside into GS extended a lot of GS > kernel classes to be Pharo / Seaside compatible. > > We have 2 Metacello configs. The one called "Runtime" loads all the > Seaside / Magritte / Whatever tools we use from the community, with > some differences between what we load into GS / Pharo. The other is > our own project that is dependent on Runtime, also with small > compatibility changes between the different environments. > > Please let me know where I can give you more info or code. > > Cheers > Otto > _______________________________________________ > Glass mailing list > [hidden email] > http://lists.gemtalksystems.com/mailman/listinfo/glass > _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Basic questions regarding GemBuilder for Smalltalk, GemTools, and tODE
|
|
On Tue, Oct 1, 2013 at 12:12 PM, Joachim Tuchel <[hidden email]> wrote:
I come from the other side who likes to write code on the gemstone server, so im puzzled why people insist on developing gemstone code in a non-gemstone image. but it seems to work well, as its a popular (and profitable) choice. As to getting at customer data? Just copy the gemstone extent file(s) to your local testing server and run a local gemstone server. Weather the extents are 10mb, or 600GB... find room somewhere. Then you are guaranteed to have the correct customer data to chase down those wierd bugs. _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Basic questions regarding GemBuilder for Smalltalk, GemTools, and tODE
|
|
On Oct 1, 2013, at 1:28 PM, Jon Paynter <[hidden email]> wrote:
> As to getting at customer data? > Just copy the gemstone extent file(s) to your local testing server and run a local gemstone server. Weather the extents are 10mb, or 600GB... find room somewhere. Then you are guaranteed to have the correct customer data to chase down those wierd bugs. Besides, if you are taking an off-site backup then why not bring it to your development machine? James _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Basic questions regarding GemBuilder for Smalltalk, GemTools, and tODE
|
|
In reply to this post by otto
Mariano,
I would second what Otto recommends ... He is living the "develop in Pharo and deploy in GemStone" life every day and as such has first hand experience and invaluable advice. GemTools is way past it's "use by date":) and tODE is targetted to replace GemTools. When tODE is ready for prime time, I expect to be providing a new round of documentation (and tODE scripts) for working with GLASS. At worst, tODE will be a better option than topaz, at best ... well, we'll just have to see:) Until then, tODE is still in development, so I would not recommend that you try using it. I encourage Otto (and others ... hint, hint) to share more about their processes and procedures ... Dale ----- Original Message ----- | From: "Otto Behrens" <[hidden email]> | To: "Mariano Martinez Peck" <[hidden email]> | Cc: [hidden email] | Sent: Tuesday, October 1, 2013 8:28:30 AM | Subject: Re: [Glass] Basic questions regarding GemBuilder for Smalltalk, GemTools, and tODE | | Mariano, | | We've been running a Seaside 3 / Magritte 3 app on GS for a while | now. | | We develop in Pharo 1.4 (suppose that could be 2). The application | works in Pharo 1.4, almost all tests run in Pharo 1.4. There are a | few | very small tests that we run in GemStone only, but to be honest I had | to search for them now because I could not remember - so we rarely | touch them. | | We then write the code to filetree and use filetree to load back into | GS via topaz. | | The only thing we use GemTools for is to hunt for bugs. If we really | can't understand why the app works in Pharo and not in GS, we use | GemTools to set a breakpoint and figure out what's going on. Once we | know, we exit GemTools and write code in Pharo. Sometimes we edit | code | using GemTools just to see how something will work if it is that | specific to GS. Also, sometimes, it helps to inspect data objects | which we only have in a GS DB. | | We do not even use GemTools to work on remote GS instances. We only | use topaz for that. Topaz is good enough for most things. In 6 years, | it happened about 2 times that we made a backup of the production DB, | copy it local and then use GemTools to debug. | | I would not consider using a GBS based tool, I would just develop in | Pharo, given that you know Pharo pretty well. GemTools is not | workable | as a development tool. And I can't imagine that tODE is. That is if | you use refactoring tools, customise your image and run things like | lint. | | Some more answers below: | | > that running tODE in GemStone could give us the | > functionality we now have in GemTools? | | I think so. I think that the energy that would have to go into tODE | to | make it more than that would be enormous, but then I would be glad to | hear otherwise. | | > Now that I have this thread already open ;) I wonder if someone has | > ever | > written some "port rules" or things to be aware when deploying to | > GemStone. | > I guess certain Pharo kernel classes/methods may not exist or | > answer | > something different, etc... And I think the answer would be around | > Grease? | > In other words, what I ask is the following: imagine (it is not the | > case | > unfortunately) I don't use any other library than seaside/magritte. | > What are | > the things that would make the port to gemstone complicated? Is | > there any | > list or conventions somewhere? | | We've used Grease and have some stuff that we did before grease | existed. And we've not been good at contributing stuff. Mainly | because | we get under pressure and then soon fall behind, sticking to older | versions. Upgrading is costly. Not sure how to improve this | situation. | | Having said this, we're willing to help and give anyone stuff we've | done to make the port easier. It is not that onerous. Dale and others | have done a lot; just to get Seaside into GS extended a lot of GS | kernel classes to be Pharo / Seaside compatible. | | We have 2 Metacello configs. The one called "Runtime" loads all the | Seaside / Magritte / Whatever tools we use from the community, with | some differences between what we load into GS / Pharo. The other is | our own project that is dependent on Runtime, also with small | compatibility changes between the different environments. | | Please let me know where I can give you more info or code. | | Cheers | Otto | _______________________________________________ | Glass mailing list | [hidden email] | http://lists.gemtalksystems.com/mailman/listinfo/glass | _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Basic questions regarding GemBuilder for Smalltalk, GemTools, and tODE
|
|
In reply to this post by Mariano Martinez Peck
From: "Mariano Martinez Peck" <[hidden email]>tODE currently has all of the functionality of GemTools, plus quite a bit of additional functionality ... The current incarnation of tODE[1] actually runs on top of Pharo2.0 instead of a web-browser ... it has been built from the ground up for remote development (tODE performance over the WAN exceeds the performance of GemTools over the LAN), but more importantly tODE is aimed at making it easy for developers to build custom tools and scripts. For example, I consider the git mergetool that I've built in tODE to be superior to any of the other git merge tools that I've used and it took around a day to put together ... I'm also focusing on "scriptablity for Smalltalk": basically you can create workspaces that are invoked from a command line (the "object shell") and take command line arguments so creating and running scripts for deployment or other repetitive tasks is very straightforward. Right now, I'm just starting up a beta program for tODE and I've got several folks lined up to take tODE for a "bleeding edge spin." Personally I haven't touched GemTools in anger since January of this year, yet I've been doing basically full time development directly in GemStone using tODE. Now that I've made myself happy with tODE, I need to find out what needs to be done to make other folks happy:) and that is the job of the beta testers. Paul DeBruicker is the first one to step up to the plate and I'm still addressing some of the things that he has identified ... tODE is being built to be "fully aware of Metacello and git" that means that metacello and git support is being baked into tODE. It is very easy to incorporate metacello/git operations into custom scripts that you use for your daily workflows... [1] http://www.slideshare.net/esug/tode-and-now-for-something-completely-different
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Basic questions regarding GemBuilder for Smalltalk, GemTools, and tODE
|
|
In reply to this post by Dale Henrichs-3
Am 02.10.2013 um 00:33 schrieb Dale K. Henrichs <[hidden email]>: I encourage Otto (and others ... hint, hint) to share more about their processes and procedures ... I agree with everything Otto said. I managed it at least the last 6 months to develop in pharo only and deploy on gemstone. It is easy in my case because I took some not too fine ways in code just to avoid having gemstone specific packages. For this I would need to tweak some of my workflows. Working that way is made easy by things like Grease. But on the other hand you learn really quick what are the differences between pharo and gemstone. For all of these there is a way of programming that runs on both platforms. So, I work on my pharo image and commit code to my repository. On a remote server I have an installation of jenkins continuous integration server. Whenever I commit, jenkins runs a build for pharo _and_ gemstone for the same code. Most of the time I discover problems when jenkins runs the test and pharo stays green while gemstone turns red. If everything looks green I update my development server with the new code. Updating the development server: The production server does a backup every night. I have a script [1] that copies the backup from the production server and recreates the image on the development server. On top of that I load the newest version from metacello. This is a very essential step. With bootstrapping the test server in the same state as the production server you test exactly what will happen later when you update the production server. For testing gemstone in more detail I can do two things: I can download the last prepared image from jenkins into my local gemstone. Or I download the last backup of my production server and recreate the image on my laptop. Finally I can connect to my development and production server with gemtools or topaz. But this happens rarely just like Otto said. Whenever an entry is added to the object log I get an email. Then I use gemtools to connect to the image and open a debugger on the problem and fix it. Apart from that it is mostly topaz usage because gemtools is too slow for me. And for updating tasks you are better off with topaz in combination with a tool like screen [2] anyway. That's because if the internet connection breaks while you are updating everything is rolled back. Norbert [1] the script the recreates an image from backup #!/bin/bash . ./env echo copying backup from 2d-concierge scp 2d-concierge:/opt/application/concierge/backup/backup.dbf.gz . echo unpacking backup gunzip backup.dbf.gz echo stopping concierge ./concierge stop > /dev/null echo cleaning data dir rm data/extent0.dbf rm data/tranlog* echo copy fresh extent copydbf /opt/gemstone/product/bin/extent0.dbf data/extent0.dbf chown -R gemstone data echo starting stone in restore mode startstone -R concierge echo restoring backup cat scripts/restore-backup.st | topaz -l -T200000 echo commiting restore cat scripts/commit-restore.st | topaz -l -T200000 echo stoping stone stopstone concierge DataCurator swordfish echo restaring stone in normal mode ./concierge start _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
|
|
> I agree with everything Otto said.
I wish my wife would. :-) > I took some not too fine ways in code just to avoid having gemstone > specific packages. Have also got some tricks here. What made a big difference is we have stubs in Pharo for GemStone classes and methods we use on them, for example System and SystemRepository. So we write GS specific code (eg to commit a transaction or migrate) in Pharo. It's been a long time since I needed to write a method that's in GS only. And we need to clean up the old ones. > On a remote > server I have an installation of jenkins continuous integration server. > Whenever I commit, jenkins runs a build for pharo _and_ gemstone for the > same code. Most of the time I discover problems when jenkins runs the test > and pharo stays green while gemstone turns red. Yes, do exactly that. Cool. > If everything looks green I > update my development server with the new code. > > Updating the development server: The production server does a backup every > night. I have a script [1] that copies the backup from the production server > and recreates the image on the development server. On top of that I load the > newest version from metacello. This is a very essential step. With > bootstrapping the test server in the same state as the production server you > test exactly what will happen later when you update the production server. Yes, do that too. Only difference is we don't have a development server. We just do it as a jenkins job. > For testing gemstone in more detail I can do two things: I can download the > last prepared image from jenkins into my local gemstone. Or I download the > last backup of my production server and recreate the image on my laptop. Also > is mostly topaz usage because gemtools is too slow for me. And for updating > tasks you are better off with topaz in combination with a tool like screen > [2] anyway. That's because if the internet connection breaks while you are > updating everything is rolled back. Yes, agree A key thing is the automation of all this. Quite some effort goes into that. _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Basic questions regarding GemBuilder for Smalltalk, GemTools, and tODE
|
|
In reply to this post by Dale Henrichs-3
First, I wanted to really appreciate all the answers I got. They were all very valuable and detailed. Thanks you very much. It is much clear now. Dale, I think I am totally confused about tODE. I have just seen the link you send to slideshare and that's not at all what I remembered about tODE. That (slideshare) look like a desktop/fat client tool (with remote stuff) based on Pharo 2.0. But...I remember watching a presentation of you which I thought it was tODE that was seaside-base. In fact I remember you saying: "yes, I did it in Seaside because it was easier for me than doing it in Morphic"...I am just crazy or that was something else?
Ok...I found it: http://seaside.gemtalksystems.com/movies/tODE_intro.mov (I remember it form the ESUG Innovation Technology Awards ;) )
So...i thought it was seaside-based so I thought it would be easy to run it inside GLASS, hence you could directly "develop" inside GemStone from any browser. Continue discussing about these tools...imagine that I want to browse a bit and learn about GemStone. I want to see which number classes I have, which methods each class can answer, etc etc. You know...explore the system (forgot for a minute about the pdf documentation). How could I do this right now (until tODE is released)? GemTools is the only way? well...maybe the seaside example of the class browser hahah
Thanks, On Tue, Oct 1, 2013 at 7:33 PM, Dale K. Henrichs <[hidden email]> wrote: Mariano, Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Basic questions regarding GemBuilder for Smalltalk, GemTools, and tODE
|
|
In reply to this post by Mariano Martinez Peck
Hi Mariano,
We're doing "develop in Pharo, deploy in Gemstone" for a couple of years now. After what Otto and Norbert said, I feel I have very few things to add. Since we are GLASS users, we are only using GemTools and Topaz to interact with a running Gemstone. We hopefully will be able to test-drive tODE really soon (hint hint ;-) GemTools is used to debug and develop gemstone-specific parts of the application. Whenever an error occurs in Gemstone, a continuation is pushed onto a persistent log (aka ObjectLog) and this can be easily inspected and debugged using the Smalltalk debugger in GemTools afterwards. We either debug directly on a production system or we make a backup copy to restore on our local machine and debug from there. When we need to develop against specific Gemstone parts (things like indexes for example), we develop on a local Gemstone install. Topaz is used to execute scripts. All upgrades (running metacello load and migration code) is run via a topaz script that is launched on the commandline. We never use Topaz for anything else. > Now that I have this thread already open ;) I wonder if someone has ever written some "port rules" or things to be aware when deploying to GemStone. I guess certain Pharo kernel classes/methods may not exist or answer something different, etc... And I think the answer would be around Grease? In other words, what I ask is the following: imagine (it is not the case unfortunately) I don't use any other library than seaside/magritte. What are the things that would make the port to gemstone complicated? Is there any list or conventions somewhere? It depends a bit what you will be making. If it's a Seaside app, the chances are that most things that work in Pharo will also work in GLASS. I am saying GLASS because the additions in GLASS to Gemstone are what makes it behave sufficiently close to a Pharo with image-based persistency. There are a couple of differences we learned to "know" and there are things we wrapped in a compatibility package (some parts contributed back but most pending). We also used an Abstract Factory pattern to differentiate those parts of the application that need Gemstone-specific code. This is mostly when we are dealing with indexes or some very specific Gemstone stuff we came to use over the years. We also made DALi: an abstraction layer for transactions that makes the app run transparantly with GLASS, Pharo-GOODS and Pharo-image-based-persistency. The library works very well but I guess it needs work/explaining to make it useable/understandable for others. To appreciate its abstraction, you need to understand how GLASS transactions for Seaside work. Here are some other rules that pop to mind: - The Gemstone compiler is more strict than Pharo's (shadowed variabes, empty statement will not compile). Grease has some "code portability" code critics which detect these cases so you can prevent them in Pharo too. - Assignments to temporaries to transfer values from one Seaside callback to another does not work in Gemstone (not even 3.x). This is often used in Seaside methods where you have multiple callbacks being triggered in the same action. There is a very easy workaround: use a valueholder object to hold the value. - GemStone's DateAndTime implementation (and related parts) includes daylight savings time (while Pharo's does not). This is great for us, but you need to know that some days have 23 hours durations and some have 25 hour durations ;-) - Use Grease when possible or plug factory methods onto the Grease framework (using class extensions) when you need them in your app _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Basic questions regarding GemBuilder for Smalltalk, GemTools, and tODE
|
|
In reply to this post by Mariano Martinez Peck
From: "Mariano Martinez Peck" <[hidden email]>Haha, the name of my recent presentation at ESUG is "tODE: And now for something completely different" and I wasn't kidding. The big problem that I had with using Seaside and the browser for tODE was in implementing the debugger ... viewing stack traces is relatively easy, but when you want to continue or step you get tangled up in the seaside code itself ... In a fat client, when the debugger pops up there is a bit of magic going on while the main UI process is put under the debugger and a new UI process is created so that the UI continues to run ... when using seaside, it takes a bigger set of magic to swap out the thread that is handling the http request... the other factor driving me away from the web-browser was the fact that it is not very easy to view multiple "windows" in a web browser ... Matthias Springer is "porting morphic" to Amber to solve that particular problem ... So the new version of tODE uses Pharo as a client, but it is not a typical "fat client".It is possible to create new window-based tools in tODE without writing any client-side code... I call it an "ultra thin client" in the presentation. In fact when Matthias finishes his work in "porting morphic" to Amber, it should be relatively straight forward to retarget tODE from Pharo to Amber. Matthias got started on this work earlier in the year when he use tODE and MagLev to create web-based interface for MagLev as part of an HPI bachelor project ... he only got so far before running into "window management" issues and decide that "morphic" needed to be ported to Amber... Today, I would recommend using GemTools for that kind of exploration. If you use GemTools, you should use it running against a stone running on a local network ... the window update events in GemTools are fired across the network, so any network latency shows up as slow response times in the tools. GemTools is based on OmniBrowser so they should be very familiar to you. You can download a one-click from the downloads page[1] and follow the instructions starting with "Define GemTools Session"[2] for setting up your GemTools client. Please ask questions here if you have trouble ... If you are writing a Seaside application, you should be able to get pretty far in your application before you have to worry about GemStone-specific code. Transactions are handled within the Seaside framework....If you end up with long running http requests (i.e,, hooking up to paypal to collect money), then you should pose your issue to this list for guidance, as there are different solutions to that problem depending upon what you are trying to do ... Dale [1] http://seaside.gemtalksystems.com/downloads.html [2] https://code.google.com/p/glassdb/wiki/GettingStartedWithGLASS#Define_GemTools_Session
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Basic questions regarding GemBuilder for Smalltalk, GemTools, and tODE
|
|
In reply to this post by Johan Brichau-3
On Wed, Oct 2, 2013 at 12:24 PM, Johan Brichau <[hidden email]> wrote: Hi Mariano, Thanks for the answer. We should really keep this thread stored somewhere! too many valuable information!
Ok, this is clear. It's similar to fuel-out a stack in Pharo :) When we need to develop against specific Gemstone parts (things like indexes for example), we develop on a local Gemstone install. Topaz is used to execute scripts. All upgrades (running metacello load and migration code) is run via a topaz script that is launched on the commandline. We never use Topaz for anything else.
OK, here I am confused. Why would GLASS help me more than plain GemStone to run my app? I GUESS this is because Seaside itself needs some extensions to GemStone (for methods that do not exist there but do in Pharo) or something like that, hence our app has already covered several of these problems (those already present for Seaside and friends)?
There are a couple of differences we learned to "know" and there are things we wrapped in a compatibility package (some parts contributed back but most pending). So this is how you solve the fact that special select: and friends for indexes use a different syntax? because in my case, I would like the app to continue running in Pharo, so this: | aTime |
aTime := Time now.
myEmployees select: {:i | aTime == i.name}
will simply not work. Did you delegate to a strategy or Abstract Factory or similar, or is there a compatibility package for Pharo that can somehow understand and parse this?
We also made DALi: an abstraction layer for transactions that makes the app run transparantly with GLASS, Pharo-GOODS and Pharo-image-based-persistency. The library works very well but I guess it needs work/explaining to make it useable/understandable for others. To appreciate its abstraction, you need to understand how GLASS transactions for Seaside work. mmm yes. Is it documented somewhere how the Seaside-sessions and related to GemStone sessions in Glass? Here are some other rules that pop to mind: interesting! - Assignments to temporaries to transfer values from one Seaside callback to another does not work in Gemstone (not even 3.x). This is often used in Seaside methods where you have multiple callbacks being triggered in the same action. There is a very easy workaround: use a valueholder object to hold the value. Cool. Thanks Johan for sharing this info. Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] Basic questions regarding GemBuilder for Smalltalk, GemTools, and tODE
|
|
> Thanks for the answer. We should really keep this thread stored somewhere! too many valuable information! It's in the mailinglist archives, but you are right: we might want to make a consolidated page with all of this ;-) > OK, here I am confused. Why would GLASS help me more than plain GemStone to run my app? I GUESS this is because Seaside itself needs some extensions to GemStone (for methods that do not exist there but do in Pharo) or something like that, hence our app has already covered several of these problems (those already present for Seaside and friends)? The Seaside implementation for Gemstone wraps every request in a transaction. In my view, this is essential to make your Seaside app behave exactly the way it would when you use image-based persistency in Pharo. There's other parts as well, but I found that an essential element to understand when moving our app to GLASS. Dale explains this way better than I do: http://gemstonesoup.wordpress.com/2007/05/07/transparent-persistence-for-seaside/ > So this is how you solve the fact that special select: and friends for indexes use a different syntax? because in my case, I would like the app to continue running in Pharo, so this: > > | aTime | > aTime := Time now. > myEmployees select: {:i | aTime == > i.name > } > > > will simply not work. Did you delegate to a strategy or Abstract Factory or similar, or is there a compatibility package for Pharo that can somehow understand and parse this? Obviously, when you develop in Pharo, you want to be able to run your application there as well. That means you need to design the application so that you can localize differences related to what storage method you are using. From the very beginning, we made the architectural design choice to be able to run Yesplan on different databases. We decided to always go for object-oriented databases, but remain independent on which one that would be. An abstract factory is indeed an essential pattern here, but so is a facade (put all those database query methods behind it). it is essential to make the necessary abstractions and use object-oriented polymorhpism and class specialization to be able to deal with the required differences. Most of the differences are related to optimizations though (indexes, reduced conflict collections, etc...). We have a compatibility package too that contains methods we used in Pharo but that do not exist in Gemstone. Most of that we can actually contribute back to GLASS but it's rather limited anyway. cheers Johan _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |