Glorp Version newer than 8.1-7
Locked
 
|
Hi there, does anybody happen to have a port of a newer version of Glorp than the one shipped by Instantiations in VA 9.2.2? IIUC, VAST ships a port of version 8.1-7, which dates back to 2015. I am still struggling with a few bugs that have been fixed in Glorp 2-3 years ago (subselects that create wrong prefixes for linked tables and such)... thx, Joachim
-- You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/c4d9817a-a820-4538-81d6-b84e182d6d0cn%40googlegroups.com. |
|
|
Just for completeness: I am talking about errors in Glorp like this one: https://groups.google.com/g/glorp-group/c/_HPQ7nYR4_k/m/JwZDP8GUAAAJ
Joachim Tuchel schrieb am Freitag, 4. September 2020 um 07:40:14 UTC+2:
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/d87abb6b-d6fe-4c42-a4b1-9311b94f8608n%40googlegroups.com. |
Re: Glorp Version newer than 8.1-7
|
|
In reply to this post by jtuchel
Hi Joachim,
Do you know if this issue also happens in Pharo? I'm not an extensive user of subselects (except for certain EXISTS kind of conditions), but maybe that is easy to cherry pick and apply in VAST. Regards! On Friday, September 4, 2020 at 2:40:14 AM UTC-3 [hidden email] wrote:
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/2eb51f12-0fbe-42ef-ab25-d83afa281420n%40googlegroups.com. |
|
|
HI Esteban, emari... schrieb am Sonntag, 6. September 2020 um 00:30:37 UTC+2: Hi Joachim, tbh, no. These models are quite some work to port to Pharo or VW. I only know that teh problems I mentioned ring a bell with Cincom developers who remember it was fixed a while ago.
well, that's exactly where I have problems: some subselectes, especially EXISTS create table prefixex like s1t2 for tables that are not referenced in the statement ( no ... table x as t2... in the select any where).
Sorry, but I think this is the worst possible scenario, and it has nothing to do with Pharo. I would produce my own little fork of Glorp on VAST (well, unfortunately, I already have one), which is neither the Cincom nor the Phaor version. If I fixed a bug and wanted to get it promoted upstream, who would I send it to? Instantiations? The Pharo community? Cincom? Let's look at some options: a) If it was integrated in the VAST version, Instantiations would create a fork of Glorp which was out of sync with teh original code. What if Instantiations then decided to upgrade to a newer version of Glorp. Would they test and integrate my fix against the original code? I guess they wouldn't accept that responsibility. They support Glorp, and if they integrated my fix, they'd have to support my fix which may or may not be good at all. If they threw away my fix when they upgraded to a newer version of Glorp and that caused any of their users trouble, they'd have to handle this or ask me if I am willing to invest my time.... Not a good situation, and I guess I wouldn't want Instantiations to go that path. b) If I sent my fix to Cincom, theyd'd first ask me whether my problem still exists in the latest Glorp version. They wouldn't want to work with/on a fix that solves a problem they've fixed already (maybe as much as 4 years ago). So I'd have to port part of my Application to Cincom Smalltalk to test whether my Glorp problem is a problem existing in the original Glorp version. If it existed, they'd probably first see if I provide a fix (which often I can't) or ask me to sign a support contract (it is their right to do so, I am not complaining about this). And even if I signed and paid for one, I'd still only have a Glorp version on VisualWorks that fixes my problem. I'd have three options then: b1) port the latest Glorp to VAST b2) wait for Instantiations to port it b3) port my project to VisualWorks Not all of them work equally well ;-) c) I can provide a fix to the Pharo community. AFAIU, there is not a big group pf people in the Pharo community who care about Glorp. They might integrate my fix into their port of Glorp (what Glorp version is currently ported to Pharo anyways? I don't really know, the Catalog Browser doesn't indicate it, it just says Glorp is only tested fo Pharo 7.0). So even given somebody (maybe you) cares about my problem and a possible fix, and if they integrated it, they'd integrate it in their more or less forked version of Glorp. It wouldn't make it into the master version at Cincom, so it wouldn't be available fo any user of VAST in the future, unless somebody convinced Cincom to integrate in their version and Instantiations to port a new version of Glorp. Sounds like a giant chance for wasted effort to me, tbh. So yes, I could possibly cherry pick a fix from either some undefined Pharo version or from the latest Cincom version. This would solve my problem at hand for now, but I'd have to take care of this special fix of mine for a s long as there is no version from Instantiations that includes my fix. I can think of a few scenarios that would make this hard and expensive, like me fixing a problem in a complete different place or manner than the maintainers of Glorp do (happened to me more than once, but I got feedback about it from Niall, so things weren't all that bad). Making a long story short: something is broken in the way Glrop progresses on various platforms. I am not even sure who to blame for it. Is it Cincom's obligation to take care of non-Cincom platforms? Should Instantiations be more active and work closer with Cincom? Would Cincom be interested and helpful in this? I really don't know. Would an official "Glorp project" work in which developers from all platforms work together and exchange code and fixes? Some kind of consortium? Who could initiate that and would have the resources to run such a project for years? I have the feeling that whatever I do to solve my problem will lead to my personal fork of Glorp. I'd like to avoid that. Joachim
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/936deaa3-fe42-4e14-a9b3-9e903beac9fcn%40googlegroups.com. |
Re: Glorp Version newer than 8.1-7
|
|
Hi Joachim,
On Mon, Sep 7, 2020 at 3:43 AM Joachim Tuchel <[hidden email]> wrote: > HI Esteban, > emari... schrieb am Sonntag, 6. September 2020 um 00:30:37 UTC+2: >> >> Hi Joachim, >> >> Do you know if this issue also happens in Pharo? > tbh, no. These models are quite some work to port to Pharo or VW. I only know that teh problems I mentioned ring a bell with Cincom developers who remember it was fixed a while ago. Having a reproducible case for this, a basic DescriptorSystem only with the classes/tables involved would be required in order to assert this. >> I'm not an extensive user of subselects (except for certain EXISTS kind of conditions), > well, that's exactly where I have problems: some subselectes, especially EXISTS create table prefixex like s1t2 for tables that are not referenced in the statement ( no ... table x as t2... in the select any where). >> but maybe that is easy to cherry pick and apply in VAST. > Sorry, but I think this is the worst possible scenario, and it has nothing to do with Pharo. I would produce my own little fork of Glorp on VAST (well, unfortunately, I already have one), which is neither the Cincom nor the Phaor version. If I fixed a bug and wanted to get it promoted upstream, who would I send it to? Instantiations? The Pharo community? Cincom? I know this is sub-optimal, but if your current needs requires fixing that, then I see no other option in the current situation. I also found something I think it is a bug in the current Pharo version, and I'm using a patched version of Glorp until I find time to write a proper test and be sure it doesn't break anything else. > Let's look at some options: <snip> > Making a long story short: something is broken in the way Glrop progresses on various platforms. I am not even sure who to blame for it. Is it Cincom's obligation to take care of non-Cincom platforms? Should Instantiations be more active and work closer with Cincom? Would Cincom be interested and helpful in this? I really don't know. Would an official "Glorp project" work in which developers from all platforms work together and exchange code and fixes? Some kind of consortium? Who could initiate that and would have the resources to run such a project for years? The maintenance of Glorp from a community perspective is broken, at least if you compare it with Seaside that is probably the top most cross-platform framework available for Smalltalk. It has been discussed here and in the Discord channel that a "canonical" version must be established, and that fixes should flow upstream to it. I don't think Cincom is going to play along with that, because they already have the canonical version, but they code and development process is isolated from the community. Even in Pharo there is the pharo-rdbms/glorp repository, but Pavel seems to have a more recent port [1] that for some reason doesn't want to merge into the main Pharo port. So it is the Balkans all over again [2], maybe not as serious as in the past, because we now have sharing tools (Githut, Tonel, .etc). But we're still not there. So we need a Champion that can: 1. Update the existing Pharo port to the latest changes in VW 2. Make Pharo the canonical implementation 3. Helps in the migration to other dialects. 3.1 VAST mostly 3.2 VW if they want to accept #2. 4. Takes care of applying fixes/enhancements done in other dialects 5. Return to step 3. Not a trivial task, but it is something that I'd been wanting to get straight since I did the Pharo port in 2016, at that point I even thought about renaming it, in anticipation of #3.2 not taking place, but then I understood that GLORP is a heritage name, just like Seaside is. At this point there are technical (merging, etc.), political (commercial) and economical (resources) things preventing this to happen. > I have the feeling that whatever I do to solve my problem will lead to my personal fork of Glorp. I'd like to avoid that. In the short term I don't see any other option given the small community of GLORP users. Unless there are more GLORP users that we're not aware of to make it worth it economically, other than for the sake of personal glory :-) Best regards, [1] https://github.com/pavel-krivanek/glorp/tree/8.3.1-23-baseline [2] https://web.archive.org/web/20130228051641/http://www.threeriversinstitute.org:80/blog/?p=466 Esteban A. Maringolo -- You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/CAJMgPC%2BJy_gNJTkiPtxe9MQfyg1iD9JE-yoaR9DZiGu1CdYnrg%40mail.gmail.com. |
Re: Glorp Version newer than 8.1-7
|
|
Joachim,
-- I'm pretty sure we had this conversation at ESUG regarding our difficulties upgrading GLORP...yes? And that reason, as we discussed in person, continues to be independent of our desire or willingness to do it. I understand that it is a frustrating situation for you. It is a frustrating position for our company, as well. I'm only voicing this here because I think its only right and fair to leave folks with the correct impression regarding this, especially in a public forum. We would be happy to participate in any community-wide efforts to solve this issue. - Seth On Monday, September 7, 2020 at 9:21:40 AM UTC-4, Esteban Maringolo wrote: Hi Joachim, You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/cf3edf58-d960-4dd5-b03b-7628b3f2d859o%40googlegroups.com. |
|
|
Seth, I know about the situation and I hope nothing I wrote sounds like I am blaming Instantiations for not providing a newer port of Glorp. All I wanted to say is that it is hard for every platform to work on fixes for Glorp without risking to uncouple themselves from Glorp. The Smalltalk universe is too small to afford a bunch of Glorp forks in the long term. Neither the Pharo Community nor Instantiations are to blame for this situation. I also know form first hand experience that people at Cincom, like Niall or David, are willing to help and are happy to learn about bugs in Glorp. My understanding is that the problem lays somewhere in the "powers that be" at their employer... It is hard, however, to talk to a developer about a problem in an ancient version of their project. I wouldn't want to discuss errors that I have fixed 3 or 4 years ago in my project. People should just update to one of my latest versions and come back if they still have problems. And I'd like to do that, but I can't, unless I do my own port or move over to another Smalltalk dialect, which the powers that be I mentioned above make unattractive to me. So I hope my comments yesterday made clear that even if I think the situation is bad, I fully understand that Instantiations cannot help me, unless you either port to the latest version (not possible as long as the powers that be are the way they are) or create your own fork of Glorp (which is an expensive endeavour and requires quite some expertise). If all of this says something negative, I think it doesn't point in the direction of Instantiations or the Pharo community. I was hoping that somebody out there already went through the process of porting a newer version of Glorp and is maybe willing to share their code and experience. The greatest thing that could happen would be that this organization (should it exist) would be willing to share their expertise with all of us and agree to hep keep this a continuous process In the end, what I really hope for is that we can free Glorp from the powers that be without destroying the project as a whole. I know we also discussed this at last year's ESUG. It would be great if we found a way to carry Glorp forward in a cooperative manner which can benefit not only Pharo and VAST, but also Cincom. So please accept my apologies if anything I wrote seems to indicate Instantiations is not doing a good job. It was clearly unintended. Joachim Seth Berman schrieb am Montag, 7. September 2020 um 16:42:33 UTC+2:
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/deb0150c-9cbe-4a46-8473-6181f32e4726n%40googlegroups.com. |
Re: Glorp Version newer than 8.1-7
|
|
Hi Joachim,
-- Thanks for your words. My only intention in commenting is to make it extra clear our position on this. I believe your follow up post expanded on some critical information that was needed for context. There are going to be folks reading this thread that don't know the actual situation. And if I were them, I might have just asked myself "Well then why doesn't Instantiations just update Glorp?". The team didn't want to leave people with that impression. As you have eluded to in your follow up post, there is a specific set of issues that need to be addressed. We're still trying to find ways to work-around them internally, but if Glorp is truly important to the Smalltalk community, then it needs to be a community-wide effort to fix. We would certainly be willing to be involved in that. - Seth On Tuesday, September 8, 2020 at 2:36:05 AM UTC-4, Joachim Tuchel wrote:
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/3b7e3f97-3a8a-4420-804f-e32a189a4952o%40googlegroups.com. |
Re: Glorp Version newer than 8.1-7
Administrator
|
In reply to this post by jtuchel
For the record, I didn't see anything in your post that could be consider critical of Instantiations. I did just look in the Cincom Public Repository for Glorp. I found that it was updated about a year ago. PackageDescription: Glorp(Bundle)Glorp Last published: September 20, 2019 by 'nross' Of course, that still includes the challenges of getting the code (needs a VW image, I think), exporting it in a an importable format, etc. There is the possibility of updating it via a personal use license version of VW and so getting changes to Niall if necessary. There are two or three dozen published Glorp things there, so getting it right could be challenging, if not frustrating. On Monday, September 7, 2020 at 11:36:05 PM UTC-7, Joachim Tuchel wrote:
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/1ee124f5-053b-4cdb-9129-545145f76250o%40googlegroups.com. |
|
|
Richard, I guess the technical problems like exporting code from VW, deciding what exactly is needed and how to import to a platform like VAST, Pharo, Squeak or maybe even Gemstone (for whatever reason) can be solved. To my understanding, the biggest hurdle is the fact that you need to have a licence of VisualWorks in order to load the code for exporting. Be it a commercial one or the PUL. I am not really sure, but I seem to understand there are limitations as to who gets a PUL and for what purpose. From personal experience, I can tell the developers involved in the development of Glorp at Cincom are very welcoming to bug reports and motivated to help - as long as they can reproduce the problem in their current version or at least one close enough to the current one. Which I really understand quite well. I cannot and do not want to ask anybody to check some problem that they might have fixed many months or even years ago. So I guess what would be needed is some effort to build some kind of community, in which Cincom and other players like Instantiations and inteerested organizations and individuals can cooperate on development and maintenance of Glorp. For Cincom, this may sound dangerous, because Glorp is the base for their StORE source code management system and therefor an important part of their commercial offerings. (Which is good news for every Glorp user: Cincom does and wants to fix bugs and extend Glorp). So the really frustrating part here is that nobody really knows who to talk to or what to do to start making Glorp a real community project. I am sure evrybody would benefit when developers from all Smalltalk platforms can participate in the process and help moving the framework forward by providing their extpertise, bug reports, fixes and requirements/ideas. I am even quite sure that despite all scepticism towards such an endeavor, most people involved tend to agree with me. All that is needed is that final step to talk to each other and start. I tried getting in touch with people to work on this, but haven't achieved anything but annoying people and giving them a feeling of being accused of (I don't really know what). Glorp is such a nice framework and is really powerful. It would be great if we could make it the gold standard for O/R mapping on all Smalltalk platforms and continue to improve it... Joachim Richard Sargent schrieb am Dienstag, 8. September 2020 um 23:54:26 UTC+2:
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/7665f454-b557-41aa-9268-e9a05c632ad8n%40googlegroups.com. |
|
|
and I forgot to say: that has been done in Pharo and VAST for specific versions in the past, so this is already a hurdle taken, even if new versions might come with new challenges. Staying in sync is the real challenge (not really a surprise). You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/ed0b502b-1357-41a2-b05a-afa343e72a0en%40googlegroups.com. |
Re: Glorp Version newer than 8.1-7
|
Administrator
|
I agree with all that you say. From what I've been hearing, it seems to be a "left hand / right hand" situation. i.e. one not knowing what the other is doing.
-- On Wednesday, September 9, 2020 at 2:19:28 AM UTC-7, Joachim Tuchel wrote:
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/89644420-8e01-4b1d-a2c5-0f9212730b78o%40googlegroups.com. |
«
Return to Instantiations
|
1 view|%1 views
| Free forum by Nabble | Edit this page |