[tode_st] tODE & GCI in Pharo 5?
Locked
12345
12345
Re: [tode_st] tODE & GCI in Pharo 5?
 
|
You mean that GsGci32xLibrary should also work with 3.3??? or we still would need a variation (subclass) still-to-be-coded for 3.3?
You received this message because you are subscribed to the Google Groups "tODE" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: [tode_st] tODE & GCI in Pharo 5?
|
|
Hi Dale, hi Mariano,
Thanks a lot for the very quick response. Indeed, I am very happy that you want to start with porting GCI to Pharo 5.0. I would actually like to have a GT-based tools on top of GCI to provide a more seamless integration with Pharo. I hope that would be Ok with you. About the port to UFFI, the API has changed a bit, but we can still easily map it to the existing one. For example: apiGciLogin: userName a: password <apicall: bool 'GciLogin' (char char) > ^self externalCallFailed ==> apiGciLogin: userName a: password ^self ffiCall: #(Boolean GciLogic (String userName, String password)) or: apiGciLogin: userName a: password ^self ffiCall: #(bool GciLogic (char* userName, char* password)) The documentation that is under development by Esteban is here: https://github.com/SquareBracketAssociates/PharoInProgress/blob/master/UnifiedFFI/UnifiedFFI.pillar Cheers, Doru > On Mar 30, 2016, at 4:05 AM, Mariano Martinez Peck <[hidden email]> wrote: > >> >> >> BTW3 In my original tode vm image I have a very large hierarchy of GciLibrary (GciLibrary allSubclasses size -> 7) for all combinations of of Gemstone 3.2, 2.2. etc etc. But with the project we are working now, we ONLY have GsGci32xLibrary. So....that means that this new CGI wrapper will only work for 3.2..... do we agree?? >> > The new GCI code is intended to support GemStone 3.2.x and later ... the Tugrik code is running in 3.3.0 ... but then that is why I want to get the travis tests working so we can verify against 3.2.x and 3.3.x ... > > > You mean that GsGci32xLibrary should also work with 3.3??? or we still would need a variation (subclass) still-to-be-coded for 3.3? > > > > Dale > > -- > You received this message because you are subscribed to the Google Groups "tODE" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. > For more options, visit https://groups.google.com/d/optout. > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- > You received this message because you are subscribed to the Google Groups "tODE" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. > For more options, visit https://groups.google.com/d/optout. -- www.tudorgirba.com www.feenk.com "From an abstract enough point of view, any two things are similar." -- You received this message because you are subscribed to the Google Groups "tODE" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: [tode_st] tODE & GCI in Pharo 5?
|
|
On 3/29/16 10:11 PM, Tudor Girba wrote: > Hi Dale, hi Mariano, > > Thanks a lot for the very quick response. > > Indeed, I am very happy that you want to start with porting GCI to Pharo 5.0. I would actually like to have a GT-based tools on top of GCI to provide a more seamless integration with Pharo. I hope that would be Ok with you. What kind of tools are you thinking of? The GCI is pretty low-level stuff, you wouldn't be confusing the GCI[1] with GBS[2] would you? Where GBS provides support for full object repolication between a client and GemStone, the GCI is the low-level RPC-like API upon which GBS is built --- but there is quite a bit that goes into GBS that is over and above the GCI .. We have no current plans to port GBS to Pharo --- it would be quite a bit of work ---- and the work that I am doing on Tugrik is aimed at providing Voyage-Mongo-style replication as a first step at making GemStone/S a persistence option for Pharo ... My plans were to start by duplicating the MongoTalk functionality so that GemStone could be plug compatible with Mongo, providing a transition path for applications to move from Mongo to GemStone/S.... But frankly I was not too sure how much work I would invest in duplicating the functionality of Mongo --- if one were to use GemStone/S instead of Mongo one could leverage the fact that Smalltalk is available on the server-side which would lead to a completely different model .... Anyway, if you were looking to do something along the lines of Tugrik then perhaps we should collaborate --- a "seamless integegration between Pharo and GemStone with GT-based tools in Pharo" is very appealing to me and I'd be willing to redirect my focus on that instead of Tugrik.... Of course you could be thinking of something entirely different :) Dale [1] https://downloads.gemtalksystems.com/docs/GemStone64/3.3.x/GS64-GemBuilderforC-3.3.pdf [2] https://gemtalksystems.com/products/gbs-vw/ > > About the port to UFFI, the API has changed a bit, but we can still easily map it to the existing one. For example: Thanks, -- You received this message because you are subscribed to the Google Groups "tODE" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: [tode_st] tODE & GCI in Pharo 5?
|
|
Hi,
I am not confusing the GBS with GCI :). I am thinking of a remote IDE that has a different interface than tODE. For this, I would need GCI and probably a layer of Proxies on top of it to allow us to work with objects remotely via OOPs. The Proxy layer would also be responsible for grouping shallow information to make rendering cheaper (like you do in tODE). Does this make it interesting for you? Cheers, Doru > On Mar 30, 2016, at 4:01 PM, Dale Henrichs <[hidden email]> wrote: > > > > On 3/29/16 10:11 PM, Tudor Girba wrote: >> Hi Dale, hi Mariano, >> >> Thanks a lot for the very quick response. >> >> Indeed, I am very happy that you want to start with porting GCI to Pharo 5.0. I would actually like to have a GT-based tools on top of GCI to provide a more seamless integration with Pharo. I hope that would be Ok with you. > What kind of tools are you thinking of? > The GCI is pretty low-level stuff, you wouldn't be confusing the GCI[1] with GBS[2] would you? > Where GBS provides support for full object repolication between a client and GemStone, the GCI is the low-level RPC-like API upon which GBS is built --- but there is quite a bit that goes into GBS that is over and above the GCI .. > We have no current plans to port GBS to Pharo --- it would be quite a bit of work ---- and the work that I am doing on Tugrik is aimed at providing Voyage-Mongo-style replication as a first step at making GemStone/S a persistence option for Pharo ... My plans were to start by duplicating the MongoTalk functionality so that GemStone could be plug compatible with Mongo, providing a transition path for applications to move from Mongo to GemStone/S.... But frankly I was not too sure how much work I would invest in duplicating the functionality of Mongo --- if one were to use GemStone/S instead of Mongo one could leverage the fact that Smalltalk is available on the server-side which would lead to a completely different model .... > > Anyway, if you were looking to do something along the lines of Tugrik then perhaps we should collaborate --- a "seamless integegration between Pharo and GemStone with GT-based tools in Pharo" is very appealing to me and I'd be willing to redirect my focus on that instead of Tugrik.... > > Of course you could be thinking of something entirely different :) > Dale > > [1] https://downloads.gemtalksystems.com/docs/GemStone64/3.3.x/GS64-GemBuilderforC-3.3.pdf > [2] https://gemtalksystems.com/products/gbs-vw/ >> >> About the port to UFFI, the API has changed a bit, but we can still easily map it to the existing one. For example: > > Thanks, > > -- > You received this message because you are subscribed to the Google Groups "tODE" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. > For more options, visit https://groups.google.com/d/optout. -- www.tudorgirba.com www.feenk.com "If you can't say why something is relevant, it probably isn't." -- You received this message because you are subscribed to the Google Groups "tODE" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: [tode_st] tODE & GCI in Pharo 5?
|
|
On 3/30/16 7:25 AM, Tudor Girba wrote: > Hi, > > I am not confusing the GBS with GCI :). I am thinking of a remote IDE that has a different interface than tODE. Very Cool! > For this, I would need GCI and probably a layer of Proxies on top of it to allow us to work with objects remotely via OOPs. The Proxy layer would also be responsible for grouping shallow information to make rendering cheaper (like you do in tODE). Have you thoughts on what the "layer of Proxies" would look like? I think the general problem is a pretty difficult nut to crack, but purpose-built "proxies" with a more meaningful/state-full presence in Pharo would be doable, I'd think ... TodeClientElements on steroids .... > Does this make it interesting for you? Haha, yes:) > Cheers, > Doru > > >> On Mar 30, 2016, at 4:01 PM, Dale Henrichs <[hidden email]> wrote: >> >> >> >> On 3/29/16 10:11 PM, Tudor Girba wrote: >>> Hi Dale, hi Mariano, >>> >>> Thanks a lot for the very quick response. >>> >>> Indeed, I am very happy that you want to start with porting GCI to Pharo 5.0. I would actually like to have a GT-based tools on top of GCI to provide a more seamless integration with Pharo. I hope that would be Ok with you. >> What kind of tools are you thinking of? >> The GCI is pretty low-level stuff, you wouldn't be confusing the GCI[1] with GBS[2] would you? >> Where GBS provides support for full object repolication between a client and GemStone, the GCI is the low-level RPC-like API upon which GBS is built --- but there is quite a bit that goes into GBS that is over and above the GCI .. >> We have no current plans to port GBS to Pharo --- it would be quite a bit of work ---- and the work that I am doing on Tugrik is aimed at providing Voyage-Mongo-style replication as a first step at making GemStone/S a persistence option for Pharo ... My plans were to start by duplicating the MongoTalk functionality so that GemStone could be plug compatible with Mongo, providing a transition path for applications to move from Mongo to GemStone/S.... But frankly I was not too sure how much work I would invest in duplicating the functionality of Mongo --- if one were to use GemStone/S instead of Mongo one could leverage the fact that Smalltalk is available on the server-side which would lead to a completely different model .... >> >> Anyway, if you were looking to do something along the lines of Tugrik then perhaps we should collaborate --- a "seamless integegration between Pharo and GemStone with GT-based tools in Pharo" is very appealing to me and I'd be willing to redirect my focus on that instead of Tugrik.... >> >> Of course you could be thinking of something entirely different :) >> Dale >> >> [1] https://downloads.gemtalksystems.com/docs/GemStone64/3.3.x/GS64-GemBuilderforC-3.3.pdf >> [2] https://gemtalksystems.com/products/gbs-vw/ >>> About the port to UFFI, the API has changed a bit, but we can still easily map it to the existing one. For example: >> Thanks, >> >> -- >> You received this message because you are subscribed to the Google Groups "tODE" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >> For more options, visit https://groups.google.com/d/optout. > -- > www.tudorgirba.com > www.feenk.com > > "If you can't say why something is relevant, > it probably isn't." > -- You received this message because you are subscribed to the Google Groups "tODE" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: [tode_st] tODE & GCI in Pharo 5?
|
|
Hi,
> On Mar 30, 2016, at 5:05 PM, Dale Henrichs <[hidden email]> wrote: > > > > On 3/30/16 7:25 AM, Tudor Girba wrote: >> Hi, >> >> I am not confusing the GBS with GCI :). I am thinking of a remote IDE that has a different interface than tODE. > Very Cool! >> For this, I would need GCI and probably a layer of Proxies on top of it to allow us to work with objects remotely via OOPs. The Proxy layer would also be responsible for grouping shallow information to make rendering cheaper (like you do in tODE). > Have you thoughts on what the "layer of Proxies" would look like? I think the general problem is a pretty difficult nut to crack, but purpose-built "proxies" with a more meaningful/state-full presence in Pharo would be doable, I'd think ... TodeClientElements on steroids …. Precisely. I want to have a set of purpose-build proxies. For example, if we would have a GTInspector interface, for each tab, we would have a dedicated proxy with all the information needed for the presentation received in one single call. Also, I believe that we can also create a little infrastructure to make the creation of these custom proxies cheap. >> Does this make it interesting for you? > Haha, yes:) Great :). So, from my point of view the roadmap would be: 1. GCI in Pharo 5.0 2. Build proxies for the inspector 3. Extend GTInspector to present these proxies 4. See about the next steps :) What do you think? Cheers, Doru >> Cheers, >> Doru >> >> >>> On Mar 30, 2016, at 4:01 PM, Dale Henrichs <[hidden email]> wrote: >>> >>> >>> >>> On 3/29/16 10:11 PM, Tudor Girba wrote: >>>> Hi Dale, hi Mariano, >>>> >>>> Thanks a lot for the very quick response. >>>> >>>> Indeed, I am very happy that you want to start with porting GCI to Pharo 5.0. I would actually like to have a GT-based tools on top of GCI to provide a more seamless integration with Pharo. I hope that would be Ok with you. >>> What kind of tools are you thinking of? >>> The GCI is pretty low-level stuff, you wouldn't be confusing the GCI[1] with GBS[2] would you? >>> Where GBS provides support for full object repolication between a client and GemStone, the GCI is the low-level RPC-like API upon which GBS is built --- but there is quite a bit that goes into GBS that is over and above the GCI .. >>> We have no current plans to port GBS to Pharo --- it would be quite a bit of work ---- and the work that I am doing on Tugrik is aimed at providing Voyage-Mongo-style replication as a first step at making GemStone/S a persistence option for Pharo ... My plans were to start by duplicating the MongoTalk functionality so that GemStone could be plug compatible with Mongo, providing a transition path for applications to move from Mongo to GemStone/S.... But frankly I was not too sure how much work I would invest in duplicating the functionality of Mongo --- if one were to use GemStone/S instead of Mongo one could leverage the fact that Smalltalk is available on the server-side which would lead to a completely different model .... >>> >>> Anyway, if you were looking to do something along the lines of Tugrik then perhaps we should collaborate --- a "seamless integegration between Pharo and GemStone with GT-based tools in Pharo" is very appealing to me and I'd be willing to redirect my focus on that instead of Tugrik.... >>> >>> Of course you could be thinking of something entirely different :) >>> Dale >>> >>> [1] https://downloads.gemtalksystems.com/docs/GemStone64/3.3.x/GS64-GemBuilderforC-3.3.pdf >>> [2] https://gemtalksystems.com/products/gbs-vw/ >>>> About the port to UFFI, the API has changed a bit, but we can still easily map it to the existing one. For example: >>> Thanks, >>> >>> -- >>> You received this message because you are subscribed to the Google Groups "tODE" group. >>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >>> For more options, visit https://groups.google.com/d/optout. >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "If you can't say why something is relevant, >> it probably isn't." >> > > -- > You received this message because you are subscribed to the Google Groups "tODE" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. > For more options, visit https://groups.google.com/d/optout. -- www.tudorgirba.com www.feenk.com "We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality." -- You received this message because you are subscribed to the Google Groups "tODE" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: [tode_st] tODE & GCI in Pharo 5?
|
|
I am dealing with 1). But note that just changing apicall: to #ffiCall: is not the only thing to do (that's the easiest part). On Wed, Mar 30, 2016 at 1:04 PM, Tudor Girba <[hidden email]> wrote: Hi, You received this message because you are subscribed to the Google Groups "tODE" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: [tode_st] tODE & GCI in Pharo 5?
|
|
In reply to this post by Mariano Martinez Peck
The GsGci32x works in 3.3 (tested) and I expect it to work with 3.2
(not yet tested) ... ao at the moment I don't think multiple classes
are needed and 3.2 will be the lowest common denominator ...
Dale On 03/29/2016 07:05 PM, Mariano
Martinez Peck wrote:
-- You received this message because you are subscribed to the Google Groups "tODE" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: [tode_st] tODE & GCI in Pharo 5?
|
|
In reply to this post by Tudor Girba-2
On 03/30/2016 09:04 AM, Tudor Girba wrote: > Hi, > > >> On Mar 30, 2016, at 5:05 PM, Dale Henrichs <[hidden email]> wrote: >> >> >> >> On 3/30/16 7:25 AM, Tudor Girba wrote: >>> Hi, >>> >>> I am not confusing the GBS with GCI :). I am thinking of a remote IDE that has a different interface than tODE. >> Very Cool! >>> For this, I would need GCI and probably a layer of Proxies on top of it to allow us to work with objects remotely via OOPs. The Proxy layer would also be responsible for grouping shallow information to make rendering cheaper (like you do in tODE). >> Have you thoughts on what the "layer of Proxies" would look like? I think the general problem is a pretty difficult nut to crack, but purpose-built "proxies" with a more meaningful/state-full presence in Pharo would be doable, I'd think ... TodeClientElements on steroids …. > Precisely. I want to have a set of purpose-build proxies. For example, if we would have a GTInspector interface, for each tab, we would have a dedicated proxy with all the information needed for the presentation received in one single call. > > Also, I believe that we can also create a little infrastructure to make the creation of these custom proxies cheap. server side ... the current smalltalk API for the tools takes objects as arguments ... like classes and the like ... I would be willing to build a proxy api that takes class names instead of classes and the like, to simplify the work for the proxies ... > >>> Does this make it interesting for you? >> Haha, yes:) > Great :). > > So, from my point of view the roadmap would be: > 1. GCI in Pharo 5.0 > 2. Build proxies for the inspector > 3. Extend GTInspector to present these proxies in parallel to 2 & 3, there would probably need to be a bit of porting/partitioning of the bits of tODE that aren't related to the GUI --- I don't think there's a lot, but there is the notion of the "wire protocol version" that allows old and new versions of tODE clients to communicate with old and new versions of tODE servers negotiation happens during login, so that would be needed at a minimum ... > 4. See about the next steps :) > > What do you think? > Sounds like a plan ... Dale -- You received this message because you are subscribed to the Google Groups "tODE" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: [tode_st] tODE & GCI in Pharo 5?
|
|
In reply to this post by Mariano Martinez Peck
On 03/30/2016 09:18 AM, Mariano Martinez Peck wrote: > I am dealing with 1). But note that just changing apicall: to > #ffiCall: is not the only thing to do (that's the easiest part). Yeah, timing is fluid for myself as well ... I'm trying to keep a number of balls in the air at once and every once in a while I have to handle a bowling ball or two that requires a lot of attention:) Dale -- You received this message because you are subscribed to the Google Groups "tODE" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: [tode_st] tODE & GCI in Pharo 5?
|
|
In reply to this post by Tudor Girba-2
On Wed, Mar 30, 2016 at 1:04 PM, Tudor Girba <[hidden email]> wrote: Hi, Once GCI tests are green in 5.0, I think we should: 1.1) Re-structure Tugric so that to load GemStone-GCI project instead of his own packages 1.2) Test/stress new GemStone-GCI with Tugric tests 1.3) If all above works correctly, we should re-structure tODE too to use new GemStone-CGI ( in a development branch if you want) and see if we can make tODE to work in 5.0. 2. Build proxies for the inspector You received this message because you are subscribed to the Google Groups "tODE" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: [tode_st] tODE & GCI in Pharo 5?
|
|
On 03/30/2016 10:52 AM, Mariano
Martinez Peck wrote:
I agree with this to the extent that I will be compelled to do quite a bit of tODE client cleanup while porting to the new GCI. For the new GUI only the login and required bits need to be functional in Pharo-5.0. The timing of the cleanup and port of the standard tODE client to Pharo-5.0 isn't strictly a prerequisite to ongoing work for the new GUI and can go on in parallel...
-- You received this message because you are subscribed to the Google Groups "tODE" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: [tode_st] tODE & GCI in Pharo 5?
|
|
Dale, I am having trouble to login as #apiGciLogin:a: answers false. The data passed as argument is correct. Ideally, I could call GciErr() to get some info about the error. But that function call is not yet working as the mapping of the error struct is not yet ready (I am waiting Esteban to add support for arrays in #fieldsDesc). So..... is there another way I could get some info of why the function answered false? Maybe there is a libgci already compiled as verbose or something that you could share with me? Of course there is nothing in the gemstone logs as it does not seem to even arrive there ;) On Wed, Mar 30, 2016 at 3:11 PM, Dale Henrichs <[hidden email]> wrote:
You received this message because you are subscribed to the Google Groups "tODE" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: [tode_st] tODE & GCI in Pharo 5?
|
|
Mariano,
I assume that you are using a session description that successfully logs in Pharo3.0/4.0? I would be interested in comparing the values for the 6 arguments that are used by apiGciSetNet and apiGciLogin since the problem may be in how those values are calculated ... If they are exactly the same then I would check the netldi log for anything ... you might need to set the -d flag (and restart manually using $GEMSTONE/bin/startnetldi) to get additional information ... it's also worth checking the stone log in case something shows up there ... If nothing shows up there, then we'll need to be able to look at the results of apiGciErr and extract the error message to find out what is wrong ... Dale On 03/30/2016 11:40 AM, Mariano
Martinez Peck wrote:
-- You received this message because you are subscribed to the Google Groups "tODE" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: [tode_st] tODE & GCI in Pharo 5?
|
|
On Wed, Mar 30, 2016 at 3:57 PM, Dale Henrichs <[hidden email]> wrote:
Yes.
Yes, I checked (by doing a print-it of each argument) and they are all exactly the same :(
Thanks Dale. I just tried that, but I still see nothing in the netldi log after my attempt to log in.
OK.... I imagined.. Ok, I am stuck until Esteban adds the array support. He said today or tomorrow...so let's wait. Cheers,
You received this message because you are subscribed to the Google Groups "tODE" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: [tode_st] tODE & GCI in Pharo 5?
|
|
In reply to this post by Dale Henrichs-3
On Wed, Mar 30, 2016 at 3:11 PM, Dale Henrichs <[hidden email]> wrote:
Indeed, it's not a prerequisite per se but I thought that testing new GCI with tODE itself could be quite a good test besides the unit tests and the turgic. But indeed, the rest of items can go in parallel, I agree!!!
You received this message because you are subscribed to the Google Groups "tODE" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: [tode_st] tODE & GCI in Pharo 5?
|
|
Dale, I got the code of Esteban and continue with the port and trying to login I get the exception number 4147 and the message: SSL library initialization failed mmmmm there might be something related with that. Any bell? Cheers, On Wed, Mar 30, 2016 at 4:50 PM, Mariano Martinez Peck <[hidden email]> wrote:
You received this message because you are subscribed to the Google Groups "tODE" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: [tode_st] tODE & GCI in Pharo 5?
|
|
Of course, I also needed to copy the libssl* from my tODE vm to my Pharo 5.0 VM. Now the testGciLogin is green :) On Wed, Mar 30, 2016 at 10:10 PM, Mariano Martinez Peck <[hidden email]> wrote:
You received this message because you are subscribed to the Google Groups "tODE" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: [tode_st] tODE & GCI in Pharo 5?
|
|
Wow. This is great news!
Doru > On Mar 31, 2016, at 4:14 AM, Mariano Martinez Peck <[hidden email]> wrote: > > Of course, I also needed to copy the libssl* from my tODE vm to my Pharo 5.0 VM. > Now the testGciLogin is green :) > > On Wed, Mar 30, 2016 at 10:10 PM, Mariano Martinez Peck <[hidden email]> wrote: > Dale, I got the code of Esteban and continue with the port and trying to login I get the exception number 4147 and the message: SSL library initialization failed > > mmmmm there might be something related with that. Any bell? > > Cheers, > > > > On Wed, Mar 30, 2016 at 4:50 PM, Mariano Martinez Peck <[hidden email]> wrote: > > > On Wed, Mar 30, 2016 at 3:11 PM, Dale Henrichs <[hidden email]> wrote: > > > On 03/30/2016 10:52 AM, Mariano Martinez Peck wrote: >> >> >> On Wed, Mar 30, 2016 at 1:04 PM, Tudor Girba <[hidden email]> wrote: >> Hi, >> >> >> > On Mar 30, 2016, at 5:05 PM, Dale Henrichs <[hidden email]> wrote: >> > >> > >> > >> > On 3/30/16 7:25 AM, Tudor Girba wrote: >> >> Hi, >> >> >> >> I am not confusing the GBS with GCI :). I am thinking of a remote IDE that has a different interface than tODE. >> > Very Cool! >> >> For this, I would need GCI and probably a layer of Proxies on top of it to allow us to work with objects remotely via OOPs. The Proxy layer would also be responsible for grouping shallow information to make rendering cheaper (like you do in tODE). >> > Have you thoughts on what the "layer of Proxies" would look like? I think the general problem is a pretty difficult nut to crack, but purpose-built "proxies" with a more meaningful/state-full presence in Pharo would be doable, I'd think ... TodeClientElements on steroids …. >> >> Precisely. I want to have a set of purpose-build proxies. For example, if we would have a GTInspector interface, for each tab, we would have a dedicated proxy with all the information needed for the presentation received in one single call. >> >> Also, I believe that we can also create a little infrastructure to make the creation of these custom proxies cheap. >> >> >> Does this make it interesting for you? >> > Haha, yes:) >> >> Great :). >> >> So, from my point of view the roadmap would be: >> 1. GCI in Pharo 5.0 >> >> Once GCI tests are green in 5.0, I think we should: >> >> 1.1) Re-structure Tugric so that to load GemStone-GCI project instead of his own packages >> 1.2) Test/stress new GemStone-GCI with Tugric tests >> 1.3) If all above works correctly, we should re-structure tODE too to use new GemStone-CGI ( in a development branch if you want) and see if we can make tODE to work in 5.0. > I agree with this to the extent that I will be compelled to do quite a bit of tODE client cleanup while porting to the new GCI. For the new GUI only the login and required bits need to be functional in Pharo-5.0. The timing of the cleanup and port of the standard tODE client to Pharo-5.0 isn't strictly a prerequisite to ongoing work for the new GUI and can go on in parallel... > > > Indeed, it's not a prerequisite per se but I thought that testing new GCI with tODE itself could be quite a good test besides the unit tests and the turgic. But indeed, the rest of items can go in parallel, I agree!!! > >> >> >> 2. Build proxies for the inspector >> 3. Extend GTInspector to present these proxies >> 4. See about the next steps :) >> >> What do you think? >> >> Cheers, >> Doru >> >> >> >> Cheers, >> >> Doru >> >> >> >> >> >>> On Mar 30, 2016, at 4:01 PM, Dale Henrichs <[hidden email]> wrote: >> >>> >> >>> >> >>> >> >>> On 3/29/16 10:11 PM, Tudor Girba wrote: >> >>>> Hi Dale, hi Mariano, >> >>>> >> >>>> Thanks a lot for the very quick response. >> >>>> >> >>>> Indeed, I am very happy that you want to start with porting GCI to Pharo 5.0. I would actually like to have a GT-based tools on top of GCI to provide a more seamless integration with Pharo. I hope that would be Ok with you. >> >>> What kind of tools are you thinking of? >> >>> The GCI is pretty low-level stuff, you wouldn't be confusing the GCI[1] with GBS[2] would you? >> >>> Where GBS provides support for full object repolication between a client and GemStone, the GCI is the low-level RPC-like API upon which GBS is built --- but there is quite a bit that goes into GBS that is over and above the GCI .. >> >>> We have no current plans to port GBS to Pharo --- it would be quite a bit of work ---- and the work that I am doing on Tugrik is aimed at providing Voyage-Mongo-style replication as a first step at making GemStone/S a persistence option for Pharo ... My plans were to start by duplicating the MongoTalk functionality so that GemStone could be plug compatible with Mongo, providing a transition path for applications to move from Mongo to GemStone/S.... But frankly I was not too sure how much work I would invest in duplicating the functionality of Mongo --- if one were to use GemStone/S instead of Mongo one could leverage the fact that Smalltalk is available on the server-side which would lead to a completely different model .... >> >>> >> >>> Anyway, if you were looking to do something along the lines of Tugrik then perhaps we should collaborate --- a "seamless integegration between Pharo and GemStone with GT-based tools in Pharo" is very appealing to me and I'd be willing to redirect my focus on that instead of Tugrik.... >> >>> >> >>> Of course you could be thinking of something entirely different :) >> >>> Dale >> >>> >> >>> [1] https://downloads.gemtalksystems.com/docs/GemStone64/3.3.x/GS64-GemBuilderforC-3.3.pdf >> >>> [2] https://gemtalksystems.com/products/gbs-vw/ >> >>>> About the port to UFFI, the API has changed a bit, but we can still easily map it to the existing one. For example: >> >>> Thanks, >> >>> >> >>> -- >> >>> You received this message because you are subscribed to the Google Groups "tODE" group. >> >>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >> >>> For more options, visit https://groups.google.com/d/optout. >> >> -- >> >> www.tudorgirba.com >> >> www.feenk.com >> >> >> >> "If you can't say why something is relevant, >> >> it probably isn't." >> >> >> > >> > -- >> > You received this message because you are subscribed to the Google Groups "tODE" group. >> > To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >> > For more options, visit https://groups.google.com/d/optout. >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "We can create beautiful models in a vacuum. >> But, to get them effective we have to deal with the inconvenience of reality." >> >> -- >> You received this message because you are subscribed to the Google Groups "tODE" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> -- >> You received this message because you are subscribed to the Google Groups "tODE" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >> For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups "tODE" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. > For more options, visit https://groups.google.com/d/optout. > > > > -- > Mariano > http://marianopeck.wordpress.com > > > > -- > Mariano > http://marianopeck.wordpress.com > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- > You received this message because you are subscribed to the Google Groups "tODE" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. > For more options, visit https://groups.google.com/d/optout. -- www.tudorgirba.com www.feenk.com "Obvious things are difficult to teach." -- You received this message because you are subscribed to the Google Groups "tODE" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Re: [tode_st] tODE & GCI in Pharo 5?
|
|
How can I test this?
Cheers, Doru > On Mar 31, 2016, at 9:05 AM, Tudor Girba <[hidden email]> wrote: > > Wow. This is great news! > > Doru > > >> On Mar 31, 2016, at 4:14 AM, Mariano Martinez Peck <[hidden email]> wrote: >> >> Of course, I also needed to copy the libssl* from my tODE vm to my Pharo 5.0 VM. >> Now the testGciLogin is green :) >> >> On Wed, Mar 30, 2016 at 10:10 PM, Mariano Martinez Peck <[hidden email]> wrote: >> Dale, I got the code of Esteban and continue with the port and trying to login I get the exception number 4147 and the message: SSL library initialization failed >> >> mmmmm there might be something related with that. Any bell? >> >> Cheers, >> >> >> >> On Wed, Mar 30, 2016 at 4:50 PM, Mariano Martinez Peck <[hidden email]> wrote: >> >> >> On Wed, Mar 30, 2016 at 3:11 PM, Dale Henrichs <[hidden email]> wrote: >> >> >> On 03/30/2016 10:52 AM, Mariano Martinez Peck wrote: >>> >>> >>> On Wed, Mar 30, 2016 at 1:04 PM, Tudor Girba <[hidden email]> wrote: >>> Hi, >>> >>> >>>> On Mar 30, 2016, at 5:05 PM, Dale Henrichs <[hidden email]> wrote: >>>> >>>> >>>> >>>> On 3/30/16 7:25 AM, Tudor Girba wrote: >>>>> Hi, >>>>> >>>>> I am not confusing the GBS with GCI :). I am thinking of a remote IDE that has a different interface than tODE. >>>> Very Cool! >>>>> For this, I would need GCI and probably a layer of Proxies on top of it to allow us to work with objects remotely via OOPs. The Proxy layer would also be responsible for grouping shallow information to make rendering cheaper (like you do in tODE). >>>> Have you thoughts on what the "layer of Proxies" would look like? I think the general problem is a pretty difficult nut to crack, but purpose-built "proxies" with a more meaningful/state-full presence in Pharo would be doable, I'd think ... TodeClientElements on steroids …. >>> >>> Precisely. I want to have a set of purpose-build proxies. For example, if we would have a GTInspector interface, for each tab, we would have a dedicated proxy with all the information needed for the presentation received in one single call. >>> >>> Also, I believe that we can also create a little infrastructure to make the creation of these custom proxies cheap. >>> >>>>> Does this make it interesting for you? >>>> Haha, yes:) >>> >>> Great :). >>> >>> So, from my point of view the roadmap would be: >>> 1. GCI in Pharo 5.0 >>> >>> Once GCI tests are green in 5.0, I think we should: >>> >>> 1.1) Re-structure Tugric so that to load GemStone-GCI project instead of his own packages >>> 1.2) Test/stress new GemStone-GCI with Tugric tests >>> 1.3) If all above works correctly, we should re-structure tODE too to use new GemStone-CGI ( in a development branch if you want) and see if we can make tODE to work in 5.0. >> I agree with this to the extent that I will be compelled to do quite a bit of tODE client cleanup while porting to the new GCI. For the new GUI only the login and required bits need to be functional in Pharo-5.0. The timing of the cleanup and port of the standard tODE client to Pharo-5.0 isn't strictly a prerequisite to ongoing work for the new GUI and can go on in parallel... >> >> >> Indeed, it's not a prerequisite per se but I thought that testing new GCI with tODE itself could be quite a good test besides the unit tests and the turgic. But indeed, the rest of items can go in parallel, I agree!!! >> >>> >>> >>> 2. Build proxies for the inspector >>> 3. Extend GTInspector to present these proxies >>> 4. See about the next steps :) >>> >>> What do you think? >>> >>> Cheers, >>> Doru >>> >>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>>> On Mar 30, 2016, at 4:01 PM, Dale Henrichs <[hidden email]> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 3/29/16 10:11 PM, Tudor Girba wrote: >>>>>>> Hi Dale, hi Mariano, >>>>>>> >>>>>>> Thanks a lot for the very quick response. >>>>>>> >>>>>>> Indeed, I am very happy that you want to start with porting GCI to Pharo 5.0. I would actually like to have a GT-based tools on top of GCI to provide a more seamless integration with Pharo. I hope that would be Ok with you. >>>>>> What kind of tools are you thinking of? >>>>>> The GCI is pretty low-level stuff, you wouldn't be confusing the GCI[1] with GBS[2] would you? >>>>>> Where GBS provides support for full object repolication between a client and GemStone, the GCI is the low-level RPC-like API upon which GBS is built --- but there is quite a bit that goes into GBS that is over and above the GCI .. >>>>>> We have no current plans to port GBS to Pharo --- it would be quite a bit of work ---- and the work that I am doing on Tugrik is aimed at providing Voyage-Mongo-style replication as a first step at making GemStone/S a persistence option for Pharo ... My plans were to start by duplicating the MongoTalk functionality so that GemStone could be plug compatible with Mongo, providing a transition path for applications to move from Mongo to GemStone/S.... But frankly I was not too sure how much work I would invest in duplicating the functionality of Mongo --- if one were to use GemStone/S instead of Mongo one could leverage the fact that Smalltalk is available on the server-side which would lead to a completely different model .... >>>>>> >>>>>> Anyway, if you were looking to do something along the lines of Tugrik then perhaps we should collaborate --- a "seamless integegration between Pharo and GemStone with GT-based tools in Pharo" is very appealing to me and I'd be willing to redirect my focus on that instead of Tugrik.... >>>>>> >>>>>> Of course you could be thinking of something entirely different :) >>>>>> Dale >>>>>> >>>>>> [1] https://downloads.gemtalksystems.com/docs/GemStone64/3.3.x/GS64-GemBuilderforC-3.3.pdf >>>>>> [2] https://gemtalksystems.com/products/gbs-vw/ >>>>>>> About the port to UFFI, the API has changed a bit, but we can still easily map it to the existing one. For example: >>>>>> Thanks, >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google Groups "tODE" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>> -- >>>>> www.tudorgirba.com >>>>> www.feenk.com >>>>> >>>>> "If you can't say why something is relevant, >>>>> it probably isn't." >>>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups "tODE" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >>>> For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "We can create beautiful models in a vacuum. >>> But, to get them effective we have to deal with the inconvenience of reality." >>> >>> -- >>> You received this message because you are subscribed to the Google Groups "tODE" group. >>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> -- >>> You received this message because you are subscribed to the Google Groups "tODE" group. >>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >>> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> You received this message because you are subscribed to the Google Groups "tODE" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> -- >> You received this message because you are subscribed to the Google Groups "tODE" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >> For more options, visit https://groups.google.com/d/optout. > > -- > www.tudorgirba.com > www.feenk.com > > "Obvious things are difficult to teach." > > > > -- www.tudorgirba.com www.feenk.com "Not knowing how to do something is not an argument for how it cannot be done." -- You received this message because you are subscribed to the Google Groups "tODE" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
«
Return to tODE
|
1 view|%1 views
| Free forum by Nabble | Edit this page |