ORM for Pharo
Locked
 
|
My prototype is getting less proto, and I found out it doesn't have
complex relations, and the system is going to perform faster if I have tables for most of it. What are the choices I have for doing ORM in Pharo? ¿Does GLORP work? ¿Any other options? I don't have a strong preference for the RDBMS engine, it can be anything (free), being it MySQL, PostgreSQL or Sql Server Express. Best regards, Esteban A. Maringolo _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Fri, Aug 14, 2009 at 6:14 PM, Esteban A. Maringolo <[hidden email]> wrote: My prototype is getting less proto, and I found out it doesn't have Yes. Glorp does work and with the 100% (850) of the tests green. I am who did the port from Squeak to Pharo. I created a GlorpPharoLoader but unfortunately it doesn't work right now because some packages were added that cause problems ( I am waiting the admin remove them). However, there are 2 things to take into consideration: 1) The Squeak/Pharo port of Glorp is VERY olde (years old). Diógenes Moreira is doing a new port but it is yet in process. 2) Glorp, as it is now, in Squeak/Pharo only works for the PostgreSQL native driver. However, ESUG (http://www.esug.org/Promotion/SummerTalk) soponsor us (SqueakDBX team) again this year to do an SqueakDBX / Glorp integration. This has 2 parts: 1) Refactor Glorp so that the SqueakDatabaseAccessor has nothing hardcoded to a particular driver but to a unified API. Then, you can implement the drivers you want. We already did this refactor and we also did the native postgresql driver (with the stuff we removed from SqueakDatabaseAccesor) and an SqueakDBX driver (that only works for PostgreSQL right now). This step is almost finished. 2) Complete the SqueakDBX Glorp driver so that it can used for all backends. We are now focusing in Oracle and MySQL. And also with the new port of Diogenes. Of course there are others options: - Magritte-RDB - SqueakSave: very very interesting project. See: http://www.hpi.uni-potsdam.de/hirschfeld/projects/sqsave/index.html - Moe Best, Mariano
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Esteban A. Maringolo
Esteban, I'm comenting this on philosophical grounds. I understand the efforts to have SqueakDBX and other ORM in Pharo are motivated by Seaside and other "production" initiatives so, again, my food for thought is more an intellectual contribution which I see as useful for Pharo as project: I don't see Pharo any time soon® having all the toolset to be able to compete in the CRUD¹ realm with more streamlined tools and besides, not matter how much theoretical work has been done on ORM, the "impedance mismatch" is still there, a recent and practicall account of this (for Squeak) can be found in http://onsmalltalk.com/simple-image-based-persistence-in-squeak also, AIDA/Web has been able to run only storing thing in the image! See Since we'll increase the educational efforts to spread Pharo, I think that as technology we should to recover a bit of Smalltalk technology and be first more Object Oriented and then see if ORM still is so needed. my 0.0199999.... -- Cesar Rabak [1] http://en.wikipedia.org/wiki/Create,_read,_update_and_delete
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ORM for Pharo -- ½ OFF
|
|
2009/8/14 <[hidden email]>
Hi! I am agree with you about the "impedance mismatch". I think that if I am free to choose a persistence strategy I would use an OODB. However, if we are talking about real enterprise application (not a simple webpage) being able to choose the persistence strategy is practically impossible. We did a survey last year and the results were that most of the times you cannot choose. Of course, the client has a lot of reasons: - The client already has a RDBMS - They had paid for it and have the license (sometimes) - They want a company's support. The only company here is Gemstone. - RDBMS has history and it is an standard - They have knowledge about it - Interaction with other system (even legazy systems) - They are afraid of using another persistence strategy - They want to use SQL - They have DBAs - The persistence is difficult to negotiate So. In my opinion, if Pharo wants to be used really as a platform for enterprise applications (competing to java, .NET, etc), it must have a good relational solution. Of course, when you are able to choose, you can go for another approach like OODB. Best, Mariano
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
I agree (and I myself have been on the Research side getting answers similar to those ones) in fact I'll add another item to your list: -- They have an "architectural steering committee" that dictates use of some RDBS I've seen this even requiring some ERP used different database engine thas suggested by supplier. . . So if we want to compete with enterprise applications we need to get into some Enterprise: We're still thinkering with printing in Pharo (and this is PITA when attempting to be platform agnostic), so no Report Generator still, no matter how well you connect to a RDBS, any slightly above trivial example CRUD application will need this support. Our present set of widgets is sleek but still not as comprehensive as the other competing approaches, and we still have not created enough baseline to have an "echo system" so third parties can augment them as it happens now with Java, .Net and happened (and still as legacy updates) in Delphi and VB. So if the goal is to reach those enterprise trench we have to find some company that would profit of having [Pharo] Smalltalk as a primary language to customize or augment their system, as today (say as sake of example, SAP has ABAP but with Netweaver is going Java, and they competitors similar path). Let's think about this: historically some (comercial) Smalltalks allowed via OLE (a.k.a. COM, etc.) to access Microsoft Office features and do things similar as VB (in fact even Tcl and Python allow that), but what is the "productivity" of programmer that finds a tutorial or an example in VB and has to "translate" it to Smalltalk? As today can we enumerate what would be an advantage of doing something in Pharo instead of some "mainstream" language just to do some GUI painting CRUD application? again my 0.01999.... Regards, -- Cesar Rabak
Em 14/08/2009 16:57, Mariano Martinez Peck < [hidden email] > escreveu:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ORM for Pharo -- ½ OFF
|
|
2009/8/14 <[hidden email]>
I don't know if I understand you. The idea and goal behind Pharo is to have the open, free, clean and robust smalltalk that we were missing for years for commercial applications. At least that's my idea of Pharo. It must be a platform and a base where you can create tools in it and with both of them create real applications. In my opinion Pharo shouldn't be associated with a particular UI (web or desktop) neither to a persistence strategy. Pharo must be the base of all that. So then you can have differents alternatives: For UI's you can have PolyMorph and the UI Builder. For Web you can have Seaside and Aida/Web. But pharo is not coupled with any of them. You will then choose the solutions that best feets your needs. In summary, I would love to use Pharo as platform to build enterprise and commercial applications. No matter how do I persist or display my objects. Best, Mariano
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Mariano, I can understand the goal be Pharo idea and goal as you post. What I'm trying to bring (and hopefully add to this discussion) is how can we arrive there. We need to narrow down the definition of "enterprise application" and see where Pharo can start to thrive. No all encompassing approach would work as notwithstanding how poweful and complete Pharo could become it will not be anytime soon. The notion that Pharo be not assotiated per se to any UI it is a strong (and I vote to maintain it) design goal but in order to push forward Pharo together with robust and clean implementation we'll need a lot of energy and effort to produce enough educational materials like tutorial, manuals, etc., it will be confusing all the time have an example that do not work in another minor variation of UI (to stay in a single topic). So I return to the point: we need to have more clear goals on what particular realm we see Pharo as feasible for enterprise development and be able to enumerate what are the advantages of Pharo versus the other approaches. Hope it is more explicit now ;-) Em 14/08/2009 20:42, Mariano Martinez Peck < [hidden email] > escreveu:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ORM for Pharo -- ½ OFF
|
|
2009/8/15 <[hidden email]>
I am totally agree. Would like to hear the board opinion.
Yes it was ;)
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Mariano Martinez Peck
+1
On Aug 15, 2009, at 1:42 AM, Mariano Martinez Peck wrote: > > > 2009/8/14 <[hidden email]> > > Mariano, > > I agree (and I myself have been on the Research side getting answers > similar to those ones) in fact I'll add another item to your list: > > -- They have an "architectural steering committee" that dictates use > of some RDBS > > I've seen this even requiring some ERP used different database > engine thas suggested by supplier. . . > > So if we want to compete with enterprise applications we need to get > into some Enterprise: > > We're still thinkering with printing in Pharo (and this is PITA when > attempting to be platform agnostic), so no Report Generator still, > no matter how well you connect to a RDBS, any slightly above trivial > example CRUD application will need this support. > > Our present set of widgets is sleek but still not as comprehensive > as the other competing approaches, and we still have not created > enough baseline to have an "echo system" so third parties can > augment them as it happens now with Java, .Net and happened (and > still as legacy updates) in Delphi and VB. > > So if the goal is to reach those enterprise trench we have to find > some company that would profit of having [Pharo] Smalltalk as a > primary language to customize or augment their system, as today (say > as sake of example, SAP has ABAP but with Netweaver is going Java, > and they competitors similar path). > > Let's think about this: historically some (comercial) Smalltalks > allowed via OLE (a.k.a. COM, etc.) to access Microsoft Office > features and do things similar as VB (in fact even Tcl and Python > allow that), but what is the "productivity" of programmer that finds > a tutorial or an example in VB and has to "translate" it to Smalltalk? > > As today can we enumerate what would be an advantage of doing > something in Pharo instead of some "mainstream" language just to do > some GUI painting CRUD application? > > I don't know if I understand you. The idea and goal behind Pharo is > to have the open, free, clean and robust smalltalk that we were > missing for years for commercial applications. At least that's my > idea of Pharo. It must be a platform and a base where you can create > tools in it and with both of them create real applications. > > In my opinion Pharo shouldn't be associated with a particular UI > (web or desktop) neither to a persistence strategy. Pharo must be > the base of all that. So then you can have differents alternatives: > For UI's you can have PolyMorph and the UI Builder. For Web you can > have Seaside and Aida/Web. But pharo is not coupled with any of > them. You will then choose the solutions that best feets your needs. > > In summary, I would love to use Pharo as platform to build > enterprise and commercial applications. No matter how do I persist > or display my objects. > > Best, > > Mariano > > > > > again my 0.01999.... > > Regards, > > -- > > Cesar Rabak > > > Em 14/08/2009 16:57, Mariano Martinez Peck < [hidden email] > > escreveu: > > > > > 2009/8/14 <[hidden email]> > Esteban, > > I'm comenting this on philosophical grounds. > > I understand the efforts to have SqueakDBX and other ORM in Pharo > are motivated by Seaside and other "production" initiatives so, > again, my food for thought is more an intellectual contribution > which I see as useful for Pharo as project: > > I don't see Pharo any time soon® having all the toolset to be able > to compete in the CRUD¹ realm with more streamlined tools and > besides, not matter how much theoretical work has been done on ORM, > the "impedance mismatch" is still there, > > Hi! I am agree with you about the "impedance mismatch". I think that > if I am free to choose a persistence strategy I would use an OODB. > However, if we are talking about real enterprise application (not a > simple webpage) being able to choose the persistence strategy is > practically impossible. We did a survey last year and the results > were that most of the times you cannot choose. Of course, the client > has a lot of reasons: > > - The client already has a RDBMS > - They had paid for it and have the license (sometimes) > - They want a company's support. The only company here is Gemstone. > - RDBMS has history and it is an standard > - They have knowledge about it > - Interaction with other system (even legazy systems) > - They are afraid of using another persistence strategy > - They want to use SQL > - They have DBAs > - The persistence is difficult to negotiate > > So. In my opinion, if Pharo wants to be used really as a platform > for enterprise applications (competing to java, .NET, etc), it must > have a good relational solution. Of course, when you are able to > choose, you can go for another approach like OODB. > > Best, > > Mariano > a recent and practicall account of this (for Squeak) can be found in > > http://onsmalltalk.com/simple-image-based-persistence-in-squeak > > also, AIDA/Web has been able to run only storing thing in the image! > See > > http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/d3ba3867767b2253/f7435102b7e35ebe?lnk=gst&q=+pure+smalltalk+e+commerce%2C+no+rdbms%2C+no+apache%2C+smalltak+%2Blinux&rnum=1#f7435102b7e35ebe > > Since we'll increase the educational efforts to spread Pharo, I > think that as technology we should to recover a bit of Smalltalk > technology and be first more Object Oriented and then see if ORM > still is so needed. > > my 0.0199999.... > > -- > > Cesar Rabak > > [1] http://en.wikipedia.org/wiki/Create,_read,_update_and_delete > Em 14/08/2009 16:14, Esteban A. Maringolo < [hidden email] > > escreveu: > > > My prototype is getting less proto, and I found out it doesn't have > complex relations, and the system is going to perform faster if I have > tables for most of it. > > What are the choices I have for doing ORM in Pharo? > > ¿Does GLORP work? ¿Any other options? > I don't have a strong preference for the RDBMS engine, it can be > anything (free), being it MySQL, PostgreSQL or Sql Server Express. > > Best regards, > > Esteban A. Maringolo > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Stef, I understand you agree with Mariano. Now how will Pharo fulfill this vision? -- Cesar Rabak PS.: See also my reply to Mariano
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
The point is that pharoers should implement the vision not pharo.
We have enough to do. The fact that pharo will succeed depends also on us as a community nor just 5 guys doing an integration of fixes. Stef > Stef, > > I understand you agree with Mariano. Now how will Pharo fulfill > this vision? > > -- > > Cesar Rabak > > PS.: See also my reply to Mariano > > Em 16/08/2009 06:12, Stéphane Ducasse < [hidden email] > > escreveu: > > > +1 > > On Aug 15, 2009, at 1:42 AM, Mariano Martinez Peck wrote: > > > > > > > 2009/8/14 > > > > Mariano, > > > > I agree (and I myself have been on the Research side getting answers > > similar to those ones) in fact I'll add another item to your list: > > > > -- They have an "architectural steering committee" that dictates use > > of some RDBS > > > > I've seen this even requiring some ERP used different database > > engine thas suggested by supplier. . . > > > > So if we want to compete with enterprise applications we need to get > > into some Enterprise: > > > > We're still thinkering with printing in Pharo (and this is PITA when > > attempting to be platform agnostic), so no Report Generator still, > > no matter how well you connect to a RDBS, any slightly above trivial > > example CRUD application will need this support. > > > > Our present set of widgets is sleek but still not as comprehensive > > as the other competing approaches, and we still have not created > > enough baseline to have an "echo system" so third parties can > > augment them as it happens now with Java, .Net and happened (and > > still as legacy updates) in Delphi and VB. > > > > So if the goal is to reach those enterprise trench we have to find > > some company that would profit of having [Pharo] Smalltalk as a > > primary language to customize or augment their system, as today (say > > as sake of example, SAP has ABAP but with Netweaver is going Java, > > and they competitors similar path). > > > > Let's think about this: historically some (comercial) Smalltalks > > allowed via OLE (a.k.a. COM, etc.) to ac cess Microsoft Office > > features and do things similar as VB (in fact even Tcl and Python > > allow that), but what is the "productivity" of programmer that finds > > a tutorial or an example in VB and has to "translate" it to > Smalltalk? > > > > As today can we enumerate what would be an advantage of doing > > something in Pharo instead of some "mainstream" language just to do > > some GUI painting CRUD application? > > > > I don't know if I understand you. The idea and goal behind Pharo is > > to have the open, free, clean and robust smalltalk that we were > > missing for years for commercial applications. At least that's my > > idea of Pharo. It must be a platform and a base where you can create > > tools in it and with both of them create real applications. > > > > In my opinion Pharo shouldn't be associated with a particular UI > > (web or desktop) neithe r to a persistence strategy. Pharo must be > > the base of all that. So then you can have differents alternatives: > > For UI's you can have PolyMorph and the UI Builder. For Web you can > > have Seaside and Aida/Web. But pharo is not coupled with any of > > them. You will then choose the solutions that best feets your needs. > > > > In summary, I would love to use Pharo as platform to build > > enterprise and commercial applications. No matter how do I persist > > or display my objects. > > > > Best, > > > > Mariano > > > > > > > > > > again my 0.01999.... > > > > Regards, > > > > -- > > > > Cesar Rabak > > > > > > Em 14/08/2009 16:57, Mariano Martinez Peck < [hidden email] > > > escreveu: > > > > > > > > > > 2009/8/14 > > Esteban, > > > > I'm comenting this on philosophical grounds. > > > > I understand the efforts to have SqueakDBX and other ORM in Pharo > > are motivated by Seaside and other "production" initiatives so, > > again, my food for thought is more an intellectual contribution > > which I see as useful for Pharo as project: > > > > I don't see Pharo any time soon® having all the toolset to be able > > to compete in the CRUD¹ realm with more streamlined tools and > > besides, not matter how much theoretical work has been done on ORM, > > the "impedance mismatch" is still there, > > > > Hi! I am agree with you about the "impedance mismatch". I think that > > if I am free to choose a persistence strategy I would use an OODB. > > However, if we are talking about real enterprise application (not a > > simple webpage) being able to choose the persistence strategy is > > practically impos sible. We did a survey last year and the results > > were that most of the times you cannot choose. Of course, the client > > has a lot of reasons: > > > > - The client already has a RDBMS > > - They had paid for it and have the license (sometimes) > > - They want a company's support. The only company here is Gemstone. > > - RDBMS has history and it is an standard > > - They have knowledge about it > > - Interaction with other system (even legazy systems) > > - They are afraid of using another persistence strategy > > - They want to use SQL > > - They have DBAs > > - The persistence is difficult to negotiate > > > > So. In my opinion, if Pharo wants to be used really as a platform > > for enterprise applications (competing to java, .NET, etc), it must > > have a good relational solution. Of course, when you are able to > > choose, you can go for another appro ach like OODB. > > > > Best, > > > > Mariano > > a recent and practicall account of this (for Squeak) can be found in > > > > http://onsmalltalk.com/simple-image-based-persistence-in-squeak > > > > also, AIDA/Web has been able to run only storing thing in the image! > > See > > > > http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/d3ba3867767b2253/f7435102b7e35ebe?lnk=gst&q=+pure+smalltalk+e+commerce%2C+no+rdbms%2C+no+apache%2C+smalltak+%2Blinux&rnum=1#f7435102b7e35ebe > > > > Since we'll increase the educational efforts to spread Pharo, I > > think that as technology we should to recover a bit of Smalltalk > > technology and be first more Object Oriented and then see if ORM > > still is so needed. > > > > my 0.0199999.... > > > > -- > > > > Cesar Rabak > > > > [1] http://en.wikipedia.org/w iki/Create,_read,_update_and_delete > > Em 14/08/2009 16:14, Esteban A. Maringolo < [hidden email] > > > escreveu: > > > > > > My prototype is getting less proto, and I found out it doesn't have > > complex relations, and the system is going to perform faster if I > have > > tables for most of it. > > > > What are the choices I have for doing ORM in Pharo? > > > > ¿Does GLORP work? ¿Any other options? > > I don't have a strong preference for the RDBMS engine, it can be > > anything (free), being it MySQL, PostgreSQL or Sql Server Express. > > > > Best regards, > > > > Esteban A. Maringolo > > > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > __________________ _____________________________ > > Pharo-project mailing list > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On 16-Aug-09, at 2:50 PM, Stéphane Ducasse wrote: > The point is that pharoers should implement the vision not pharo. > We have enough to do. The fact that pharo will succeed depends also on > us as > a community nor just 5 guys doing an integration of fixes. > > Stef Ok let's talk about bug http://code.google.com/p/pharo/issues/detail?id=1068&q=quit&colspec=ID%20Type%20Status%20Summary%20Milestone Part of this is the *purge* of the string Squeak from the image, so Quit Squeak Vm doesn't fire the quit logic (a) I'd rather not have to build two VMs, one for Squeak and one for Pharo (b) Also I'd rather not have to answer is the Pharo VM different from the Squeak VM? (c) If you take the Squeak.app and rename it all to Pharo then someone has to manage that process and ensure the Pharo clone is cloned properly from the Squeak.app (d) if you have a Pharo.app the question then is where did it come from? (e) I do agree having a Pharo app, then seeing quit Squeak VM is very confusing, therefore people should be able to change that to suit their needs. So how would people like to see how this would work. This of course precludes any discussion of how the linux & windows versions behave and give textual feedback. -- = = = ======================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by csrabak
IMHO
Pharo must stick to the roadmap milestones, keeping clear boundaries on what
goes in and out - I value that some people are acting as
gatekeepers.
Then a
second community, those who develop frameworks that run on top of Pharo, like
the authors of frameworks of Seaside, Glorp,,SqueakDBX (to name a few
coming from the top of my head) may probably try to ensure their
frameworks progresses aligned with the Pharo releases, demanding a rrobust and
performant Smalltalk system impementattion.
Now,
to boost Pharo adoption, beyod smalltalkers, and to capture the attention of new
people, probably not familiar with the language, technology, style, the system
itself, the paradigm, and (why not) the culture,, a new foundation of spin-off
should address the level of effort to envision and manufacture...
#1 a
rich set of widgets and
#2
recipes showing how to combine them to produce high-impact realtime client GUIs
As an
example I mention what
-
Swing, AWT and SWT is for Java,
- Tk
is for Tcl,
- GTK+
to C++, (and lots of....)
-
UIPaainter to VisualWorks,
and so
on..:)
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Squeak versus Pharo as application name
|
|
In reply to this post by johnmci
Why are the menus not being built from within the image/and/or the
path/name of the executable? On Aug 16, 2009, at 5:25 PM, John M McIntosh wrote: > > On 16-Aug-09, at 2:50 PM, Stéphane Ducasse wrote: > >> The point is that pharoers should implement the vision not pharo. >> We have enough to do. The fact that pharo will succeed depends also >> on >> us as >> a community nor just 5 guys doing an integration of fixes. >> >> Stef > > Ok let's talk about bug http://code.google.com/p/pharo/issues/detail?id=1068&q=quit&colspec=ID%20Type%20Status%20Summary%20Milestone > > Part of this is the *purge* of the string Squeak from the image, so > Quit Squeak Vm doesn't fire the quit logic > > (a) I'd rather not have to build two VMs, one for Squeak and one for > Pharo > (b) Also I'd rather not have to answer is the Pharo VM different from > the Squeak VM? > (c) If you take the Squeak.app and rename it all to Pharo then someone > has to manage that process and ensure the Pharo clone is cloned > properly from the Squeak.app > (d) if you have a Pharo.app the question then is where did it come > from? > (e) I do agree having a Pharo app, then seeing quit Squeak VM is very > confusing, therefore people should be able to change that to suit > their needs. > > So how would people like to see how this would work. > > This of course precludes any discussion of how the linux & windows > versions behave and give textual feedback. > > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <[hidden email]> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Squeak versus Pharo as application name
|
|
In reply to this post by johnmci
The simplest for you and
On Aug 17, 2009, at 2:25 AM, John M McIntosh wrote: > > On 16-Aug-09, at 2:50 PM, Stéphane Ducasse wrote: > >> The point is that pharoers should implement the vision not pharo. >> We have enough to do. The fact that pharo will succeed depends also >> on >> us as >> a community nor just 5 guys doing an integration of fixes. >> >> Stef > > Ok let's talk about bug http://code.google.com/p/pharo/issues/detail?id=1068&q=quit&colspec=ID%20Type%20Status%20Summary%20Milestone > > Part of this is the *purge* of the string Squeak from the image, so > Quit Squeak Vm doesn't fire the quit logic > > (a) I'd rather not have to build two VMs, one for Squeak and one for > Pharo agree. Now does the event cleaning and other have no impact on the vm level? > (b) Also I'd rather not have to answer is the Pharo VM different from > the Squeak VM? agree > (c) If you take the Squeak.app and rename it all to Pharo then someone > has to manage that process and ensure the Pharo clone is cloned > properly from the Squeak.app yes may be we could have a script for that > (d) if you have a Pharo.app the question then is where did it come > from? **We** could have a script for transforming squeakvm into pharo vm > (e) I do agree having a Pharo app, then seeing quit Squeak VM is very > confusing, therefore people should be able to change that to suit > their needs. may be we should use platform and extend it to vm or system name > > So how would people like to see how this would work. > > This of course precludes any discussion of how the linux & windows > versions behave and give textual feedback. > > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <[hidden email]> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Squeak versus Pharo as application name
|
|
I think that the name has to come from the executable. The idea of
Pharo is to have a Smalltalk that can be shipped. So if someone were to create an application and wanted a custom wrapped double clickable file with a name like - oh - Sophie.app - then it would adjust the menus appropriately. On Aug 16, 2009, at 11:37 PM, Stéphane Ducasse wrote: > The simplest for you and > > On Aug 17, 2009, at 2:25 AM, John M McIntosh wrote: > >> >> On 16-Aug-09, at 2:50 PM, Stéphane Ducasse wrote: >> >>> The point is that pharoers should implement the vision not pharo. >>> We have enough to do. The fact that pharo will succeed depends also >>> on >>> us as >>> a community nor just 5 guys doing an integration of fixes. >>> >>> Stef >> >> Ok let's talk about bug http://code.google.com/p/pharo/issues/detail?id=1068&q=quit&colspec=ID%20Type%20Status%20Summary%20Milestone >> >> Part of this is the *purge* of the string Squeak from the image, so >> Quit Squeak Vm doesn't fire the quit logic >> >> (a) I'd rather not have to build two VMs, one for Squeak and one for >> Pharo > > agree. Now does the event cleaning and other have no impact on the vm > level? > >> (b) Also I'd rather not have to answer is the Pharo VM different from >> the Squeak VM? > agree > >> (c) If you take the Squeak.app and rename it all to Pharo then >> someone >> has to manage that process and ensure the Pharo clone is cloned >> properly from the Squeak.app > > yes may be we could have a script for that > >> (d) if you have a Pharo.app the question then is where did it come >> from? > > **We** could have a script for transforming squeakvm into pharo vm > >> (e) I do agree having a Pharo app, then seeing quit Squeak VM is very >> confusing, therefore people should be able to change that to suit >> their needs. > > may be we should use platform and extend it to vm or system name >> >> So how would people like to see how this would work. >> >> This of course precludes any discussion of how the linux & windows >> versions behave and give textual feedback. >> >> >> -- >> = >> = >> = >> = >> = >> = >> ===================================================================== >> John M. McIntosh <[hidden email]> Twitter: >> squeaker68882 >> Corporate Smalltalk Consulting Ltd. http:// >> www.smalltalkconsulting.com >> = >> = >> = >> = >> = >> = >> ===================================================================== >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Squeak versus Pharo as application name
|
|
In reply to this post by johnmci
Hello,
I cleaned the menues, and moved things into the first menu that normally are there for all other Mac apps. For example all the Quit entries, "About" and "Preferences". Now, all these are not about "Squeak VM", but about "Pharo". So I checked a bit to see how Sophie had a nice Sophie menu, and I found that changing the info.plist would change the menu. I than stopped. So now we need to think about what to do. Do we want a "Squeak VM" menu with a "Preferences" entry that than is not about "Squeak VM"? I don't think so... Marcus On 16.08.2009, at 20:25, John M McIntosh wrote: > > On 16-Aug-09, at 2:50 PM, Stéphane Ducasse wrote: > >> The point is that pharoers should implement the vision not pharo. >> We have enough to do. The fact that pharo will succeed depends also >> on >> us as >> a community nor just 5 guys doing an integration of fixes. >> >> Stef > > Ok let's talk about bug http://code.google.com/p/pharo/issues/detail?id=1068&q=quit&colspec=ID%20Type%20Status%20Summary%20Milestone > > Part of this is the *purge* of the string Squeak from the image, so > Quit Squeak Vm doesn't fire the quit logic > > (a) I'd rather not have to build two VMs, one for Squeak and one for > Pharo > (b) Also I'd rather not have to answer is the Pharo VM different from > the Squeak VM? > (c) If you take the Squeak.app and rename it all to Pharo then someone > has to manage that process and ensure the Pharo clone is cloned > properly from the Squeak.app > (d) if you have a Pharo.app the question then is where did it come > from? > (e) I do agree having a Pharo app, then seeing quit Squeak VM is very > confusing, therefore people should be able to change that to suit > their needs. > > So how would people like to see how this would work. > > This of course precludes any discussion of how the linux & windows > versions behave and give textual feedback. > > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <[hidden email]> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ORM for Pharo -- ½ OFF
|
|
In reply to this post by Carlos Crosetti-4
I'm arriving late to this discussion...
I think that having a good ORM solution is important to enterprise applications... and not only enterprise but if you have tables with LOTS of rows, you need to map them to objects. Don't start talking about Gemstone, I like, it's rock solid, but sometimes, most of the times I would say, it's out of the discussion. Even with objects mapped to tables, you can do real good object programming. I don't want to see another isolated Smalltalk again, the more able you are to interconnect with the external world, the better. Regards, Esteban A. Maringolo 2009/8/16 Carlos Crosetti <[hidden email]>: > IMHO Pharo must stick to the roadmap milestones, keeping clear boundaries on > what goes in and out - I value that some people are acting as gatekeepers. > > Then a second community, those who develop frameworks that run on top of > Pharo, like the authors of frameworks of Seaside, Glorp,,SqueakDBX (to name > a few coming from the top of my head) may probably try to ensure their > frameworks progresses aligned with the Pharo releases, demanding a rrobust > and performant Smalltalk system impementattion. > > Now, to boost Pharo adoption, beyod smalltalkers, and to capture the > attention of new people, probably not familiar with the language, > technology, style, the system itself, the paradigm, and (why not) the > culture,, a new foundation of spin-off should address the level of effort to > envision and manufacture... > #1 a rich set of widgets and > #2 recipes showing how to combine them to produce high-impact realtime > client GUIs > > As an example I mention what > - Swing, AWT and SWT is for Java, > - Tk is for Tcl, > - GTK+ to C++, (and lots of....) > - UIPaainter to VisualWorks, > > and so on..:) > > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]]En nombre de > [hidden email] > Enviado el: Sábado, 15 de Agosto de 2009 01:04 p.m. > Para: [hidden email] > Asunto: Re: [Pharo-project] ORM for Pharo -- ½ OFF > > Mariano, > > I can understand the goal be Pharo idea and goal as you post. What I'm > trying to bring (and hopefully add to this discussion) is how can we arrive > there. > > We need to narrow down the definition of "enterprise application" and see > where Pharo can start to thrive. No all encompassing approach would work as > notwithstanding how poweful and complete Pharo could become it will not be > anytime soon. > > The notion that Pharo be not assotiated per se to any UI it is a strong (and > I vote to maintain it) design goal but in order to push forward Pharo > together with robust and clean implementation we'll need a lot of energy and > effort to produce enough educational materials like tutorial, manuals, etc., > it will be confusing all the time have an example that do not work in > another minor variation of UI (to stay in a single topic). > > So I return to the point: we need to have more clear goals on what > particular realm we see Pharo as feasible for enterprise development and be > able to enumerate what are the advantages of Pharo versus the other > approaches. > > Hope it is more explicit now ;-) > > Em 14/08/2009 20:42, Mariano Martinez Peck < [hidden email] > > escreveu: > > > 2009/8/14 <[hidden email]> >> >> Mariano, >> >> I agree (and I myself have been on the Research side getting answers >> similar to those ones) in fact I'll add another item to your list: >> >> -- They have an "architectural steering committee" that dictates use of >> some RDBS >> >> I've seen this even requiring some ERP used different database engine thas >> suggested by supplier. . . >> >> So if we want to compete with enterprise applications we need to get into >> some Enterprise: >> >> We're still thinkering with printing in Pharo (and this is PITA when >> attempting to be platform agnostic), so no Report Generator still, no matter >> how well you connect to a RDBS, any slightly above trivial example CRUD >> application will need this support. >> >> Our present set of widgets is sleek but still not as comprehensive as the >> other competing approaches, and we still have not created enough baseline to >> have an "echo system" so third parties can augment them as it happens now >> with Java, .Net and happened (and still as legacy updates) in Delphi and VB. >> >> So if the goal is to reach those enterprise trench we have to find some >> company that would profit of having [Pharo] Smalltalk as a primary language >> to customize or augment their system, as today (say as sake of example, SAP >> has ABAP but with Netweaver is going Java, and they competitors similar >> path). >> >> Let's think about this: historically some (comercial) Smalltalks allowed >> via OLE (a.k.a. COM, etc.) to access Microsoft Office features and do things >> similar as VB (in fact even Tcl and Python allow that), but what is the >> "productivity" of programmer that finds a tutorial or an example in VB and >> has to "translate" it to Smalltalk? >> >> As today can we enumerate what would be an advantage of doing something in >> Pharo instead of some "mainstream" language just to do some GUI painting >> CRUD application? > > I don't know if I understand you. The idea and goal behind Pharo is to have > the open, free, clean and robust smalltalk that we were missing for years > for commercial applications. At least that's my idea of Pharo. It must be a > platform and a base where you can create tools in it and with both of them > create real applications. > > In my opinion Pharo shouldn't be associated with a particular UI (web or > desktop) neither to a persistence strategy. Pharo must be the base of all > that. So then you can have differents alternatives: For UI's you can have > PolyMorph and the UI Builder. For Web you can have Seaside and Aida/Web. But > pharo is not coupled with any of them. You will then choose the solutions > that best feets your needs. > > In summary, I would love to use Pharo as platform to build enterprise and > commercial applications. No matter how do I persist or display my objects. > > Best, > > Mariano > > >> >> >> again my 0.01999.... >> >> Regards, >> >> -- >> >> Cesar Rabak >> >> >> >> Em 14/08/2009 16:57, Mariano Martinez Peck < [hidden email] > >> escreveu: >> >> >> 2009/8/14 <[hidden email]> >>> >>> Esteban, >>> >>> I'm comenting this on philosophical grounds. >>> >>> I understand the efforts to have SqueakDBX and other ORM in Pharo are >>> motivated by Seaside and other "production" initiatives so, again, my food >>> for thought is more an intellectual contribution which I see as useful for >>> Pharo as project: >>> >>> I don't see Pharo any time soon® having all the toolset to be able to >>> compete in the CRUD¹ realm with more streamlined tools and besides, not >>> matter how much theoretical work has been done on ORM, the "impedance >>> mismatch" is still there, >> >> Hi! I am agree with you about the "impedance mismatch". I think that if I >> am free to choose a persistence strategy I would use an OODB. However, if we >> are talking about real enterprise application (not a simple webpage) being >> able to choose the persistence strategy is practically impossible. We did a >> survey last year and the results were that most of the times you cannot >> choose. Of course, the client has a lot of reasons: >> >> - The client already has a RDBMS >> - They had paid for it and have the license (sometimes) >> - They want a company's support. The only company here is Gemstone. >> - RDBMS has history and it is an standard >> - They have knowledge about it >> - Interaction with other system (even legazy systems) >> - They are afraid of using another persistence strategy >> - They want to use SQL >> - They have DBAs >> - The persistence is difficult to negotiate >> >> So. In my opinion, if Pharo wants to be used really as a platform for >> enterprise applications (competing to java, .NET, etc), it must have a good >> relational solution. Of course, when you are able to choose, you can go for >> another approach like OODB. >> >> Best, >> >> Mariano >>> >>> a recent and practicall account of this (for Squeak) can be found in >>> >>> http://onsmalltalk.com/simple-image-based-persistence-in-squeak >>> >>> also, AIDA/Web has been able to run only storing thing in the image! See >>> >>> >>> http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/d3ba3867767b2253/f7435102b7e35ebe?lnk=gst&q=+pure+smalltalk+e+commerce%2C+no+rdbms%2C+no+apache%2C+smalltak+%2Blinux&rnum=1#f7435102b7e35ebe >>> >>> Since we'll increase the educational efforts to spread Pharo, I think >>> that as technology we should to recover a bit of Smalltalk technology and be >>> first more Object Oriented and then see if ORM still is so needed. >>> >>> my 0.0199999.... >>> >>> -- >>> >>> Cesar Rabak >>> >>> [1] http://en.wikipedia.org/wiki/Create,_read,_update_and_delete >>> Em 14/08/2009 16:14, Esteban A. Maringolo < [hidden email] > >>> escreveu: >>> >>> My prototype is getting less proto, and I found out it doesn't have >>> complex relations, and the system is going to perform faster if I have >>> tables for most of it. >>> >>> What are the choices I have for doing ORM in Pharo? >>> >>> ¿Does GLORP work? ¿Any other options? >>> I don't have a strong preference for the RDBMS engine, it can be >>> anything (free), being it MySQL, PostgreSQL or Sql Server Express. >>> >>> Best regards, >>> >>> Esteban A. Maringolo >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Mariano Martinez Peck
SqueakSave seems to bee pretty attractive, does it work in Pharo?
Shouldn't it be PharoSave? :) Regards! Esteban A. Maringolo _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Tue, Aug 18, 2009 at 10:55 AM, Esteban A. Maringolo <[hidden email]> wrote: SqueakSave seems to bee pretty attractive, does it work in Pharo? hehehehe I did the same question to him. Actually, I have been sending several private emails with hie because as SqueakSave works for PostgreSQL and MySQL native drivers he had to do a lot of effort. Now, he thought to replace all that stuff with SqueakDBX. Regarding to your question, he told me he didn't tested yet, but wanted to do it before ESUG (he also goes there). But we can ask him again if it was tested. However, take into account this project is still in development, not productive. But sound REALLY interesting. They have a lot of people using it there. It seems to be a very good solution for small/medium app where I don't want to spend time doing mappings, something like active record ?
I am sorry I am not agree. I, as a software developer, would like that my project works not only in Pharo but also in all of its forks. SqueakDBX runs in Squeak, Pharo and (I didn't test it) but should work in Cuis (and if not, let me know please) or whatever other squeak fork. I put the name of the abstract class ;) Cheers, Mariano
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
| Free forum by Nabble | Edit this page |