[Pharo-project] Developer guide ... ?
Hi folks! I really would appreciate some sort of "orientation" in this jungle of code in Pharo/Squeak ... 1. What classes are compatible to other smalltalks? When i follow mailing-lists of Dolphin, Squeak, VW, VA Magma - there still is a bunch of porting problems. Why?????? What classes should i give preference to minimize porting cost? 2. Interfaces ... hmmm, well ... there are many programmes thinking in categories of "interfaces", "libraries", "class dependencies", e.t.c. Of course, Smalltalk is something completely different, but it makes it difficult for s.b. e.g. coming from Java or C++, to find into Smalltalk concepts. Gofer - till now, i have just a wage imagination, what it's good for ... 3. GUI builder. IMHO, it's very easy to build a GUI with morphic. In Squeak, e.g. i simply generate my input forms with EToys, which can be replaced of course by a few lines of code typed in by hand ... But for developers coming from Java, C++ ... the first ask for a GUI builder and XAML e.t.c. There should be some documentation, that leads programmers, that are willing to switch over to Smalltalk, into the right direction. Just a few examples, e.g. how to build a form, that scrolls through some MySQL data sets, really would help. What about compatibility? Is Morphic portable to other Smalltalks? 4. Multitasking, green threads, ... There are really missing some pointers, howto code e.g. a background process that is fetching some data from e.g. MySQL or reading/writing large files, sending data over network - without freezing the GUI. 5. Standards: XML-RPC, SOAP, RMI, CORBA, .... encryption (SSL) ... Without having a precise idea, where to find working examples to exchance data with other systems, i would hesitate to begin to do projects with Pharo/Squeak ... 6. Databases: Magma seems to be fine as database, but also dog slow. I really hesitate to start serious projects with Magma. 7. Speed, Memory consumption, Quality of modern algorithms: When working with Seaside, PIER ... that stuff is dog slow, memory consuption is hardly predictable. That makes webhosting e.g. on vservers absolutely impossible, the whole system quickly becomes unstable. IMHO in Pharo there are routines, that really waste a lot of memory, that could be programmed in a more intelligent way, expecially collection's algorithms ... ;-) Perhaps Donald Knuth books ("Art of Computer Programming") could help? Where e.g. is 'fulltext hash' or 'fulltext search' implemented in Magma, e.t.c.? Whole world works with fulltext databases (Google, MySQL, PostgreSQL, even MSSQL, Oracle). Thats 'state of the art'!!!!!!!! Search in TB databases in milliseconds! so far my 0.0199999999⬠Keep up the good work on Pharo, it's still a long way to go! regards, Guido Stepken -- View this message in context: http://n2.nabble.com/Developer-guide-tp4233838p4233838.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
1. What classes are compatible to other smalltalks? When i follow mailing-lists of Dolphin, Squeak, VW, VA Magma - there still is a bunch of porting problems. Why?????? What classes should i give preference to minimize porting cost?
http://www.seaside.st/community/conventions (Portability)
2. Interfaces ... hmmm, well ... there are many programmes thinking in categories of "interfaces", "libraries", "class dependencies", e.t.c. Of course, Smalltalk is something completely different, but it makes it difficult for s.b. e.g. coming from Java or C++, to find into Smalltalk concepts. Gofer - till now, i have just a wage imagination, what it's good for ...
Don't know what you are talking about?
3. GUI builder. IMHO, it's very easy to build a GUI with morphic. In Squeak, e.g. i simply generate my input forms with EToys, which can be replaced of course by a few lines of code typed in by hand ... But for developers coming from Java, C++ ... the first ask for a GUI builder and XAML e.t.c. There should be some documentation, that leads programmers, that are willing to switch over to Smalltalk, into the right direction. Just a few examples, e.g. how to build a form, that scrolls through some MySQL data sets, really would help. What about compatibility? Is Morphic portable to other Smalltalks?
No.
4. Multitasking, green threads, ... There are really missing some pointers, howto code e.g. a background process that is fetching some data from e.g. MySQL or reading/writing large files, sending data over network - Â without freezing the GUI.
[ self writeLargeFile ] fork
5. Standards: XML-RPC, SOAP, RMI, CORBA, .... encryption (SSL) ... Without having a precise idea, where to find working examples to exchance data with other systems, i would hesitate to begin to do projects with Pharo/Squeak ...
6. Databases: Magma seems to be fine as database, but also dog slow. I really hesitate to start serious projects with Magma.
GemStone/S
7. Speed, Memory consumption, Quality of modern algorithms: When working with Seaside, PIER ... that stuff is dog slow
Compared to what?
That makes webhosting e.g. on vservers absolutely impossible, the whole system quickly becomes unstable. IMHO in Pharo there are routines, that really waste a lot of memory, that could be programmed in a more intelligent way, expecially collection's algorithms ... ;-)
There is a submission process for improvements. Feel free to contribute. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
4. Multitasking, green threads, ... There are really missing some pointers, howto code e.g. a background process that is fetching some data from e.g. MySQL or reading/writing large files, sending data over network - without freezing the GUI.
[ self writeLargeFile ] fork
This is not actually true if the database driver has to use FFI to communicate to an external librarym since FFI locks the complete VM while a function is being executed. So, in certain percentage, he is right.
5. Standards: XML-RPC, SOAP, RMI, CORBA, .... encryption (SSL) ... Without having a precise idea, where to find working examples to exchance data with other systems, i would hesitate to begin to do projects with Pharo/Squeak ...
6. Databases: Magma seems to be fine as database, but also dog slow. I really hesitate to start serious projects with Magma.
GemStone/S
7. Speed, Memory consumption, Quality of modern algorithms: When working with Seaside, PIER ... that stuff is dog slow
Compared to what?
That makes webhosting e.g. on vservers absolutely impossible, the whole system quickly becomes unstable. IMHO in Pharo there are routines, that really waste a lot of memory, that could be programmed in a more intelligent way, expecially collection's algorithms ... ;-)
There is a submission process for improvements. Feel free to contribute.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Mariano, 2009/12/30 Mariano Martinez Peck <marianopeck@gmail.com>:
4. Multitasking, green threads, ... There are really missing some pointers, howto code e.g. a background process that is fetching some data from e.g. MySQL or reading/writing large files, sending data over network - Â without freezing the GUI.
[ self writeLargeFile ] fork
This is not actually true if the database driver has to use FFI to communicate to an external librarym since FFI locks the complete VM while a function is being executed. So, in certain percentage, he is right.
I think sometimes this depends of the library itself, for example in the ZOOM API for the Z39.50 protocol you may specify an async parameter in the connection mode for operating asynchronously, then you would have non-blocking calls with the exception of event polling. Cheers, Hernán
On Wed, Dec 30, 2009 at 11:24 PM, Hernán Morales Durand < hernan.morales@gmail.com> wrote:
Hi Mariano,
2009/12/30 Mariano Martinez Peck <marianopeck@gmail.com>:
4. Multitasking, green threads, ... There are really missing some pointers, howto code e.g. a background process that is fetching some data from e.g. MySQL or reading/writing large files, sending data over network - without freezing the GUI.
[ self writeLargeFile ] fork
This is not actually true if the database driver has to use FFI to communicate to an external librarym since FFI locks the complete VM while
a
function is being executed. So, in certain percentage, he is right.
I think sometimes this depends of the library itself, for example in the ZOOM API for the Z39.50 protocol you may specify an async parameter in the connection mode for operating asynchronously, then you would have non-blocking calls with the exception of event polling.
Yes, true, that's exactly what we are doing in SqueakDBX, but it depends not only on OpenDBX but in the database client library :( Anyway...I would like not to block the whole VM never :)
Cheers,
Hernán
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/12/30 Guido Stepken <gstepken@googlemail.com>:
Hi folks!
I really would appreciate some sort of "orientation" in this jungle of code in Pharo/Squeak ...
1. What classes are compatible to other smalltalks? When i follow mailing-lists of Dolphin, Squeak, VW, VA Magma - there still is a bunch of porting problems. Why?????? What classes should i give preference to minimize porting cost?
I have that information in my personal Swiki, too many pages to share and didn't see a potential profit since I have to search for work in .Net/Java now :(
2. Interfaces ... hmmm, well ... there are many programmes thinking in categories of "interfaces", "libraries", "class dependencies", e.t.c. Of course, Smalltalk is something completely different, but it makes it difficult for s.b. e.g. coming from Java or C++, to find into Smalltalk concepts. Gofer - till now, i have just a wage imagination, what it's good for ...
3. GUI builder. IMHO, it's very easy to build a GUI with morphic. In Squeak, e.g. i simply generate my input forms with EToys, which can be replaced of course by a few lines of code typed in by hand ... But for developers coming from Java, C++ ... the first ask for a GUI builder and XAML e.t.c. There should be some documentation, that leads programmers, that are willing to switch over to Smalltalk, into the right direction. Just a few examples, e.g. how to build a form, that scrolls through some MySQL data sets, really would help. What about compatibility? Is Morphic portable to other Smalltalks?
4. Multitasking, green threads, ... There are really missing some pointers, howto code e.g. a background process that is fetching some data from e.g. MySQL or reading/writing large files, sending data over network - Â without freezing the GUI.
Have you tried? http://wiki.squeak.org/squeak/2978
5. Standards: XML-RPC, SOAP, RMI, CORBA, .... encryption (SSL) ... Without having a precise idea, where to find working examples to exchance data with other systems, i would hesitate to begin to do projects with Pharo/Squeak ...
6. Databases: Magma seems to be fine as database, but also dog slow. I really hesitate to start serious projects with Magma.
Then start one like we did in CONICET in Argentina, see http://documentosyobjetos.ning.com/video/opus-series-impresas-y-en (that's a video of the first FRBRoo implementation in Smalltalk, using Seaside and Magma)
7. Speed, Memory consumption, Quality of modern algorithms: When working with Seaside, PIER ... that stuff is dog slow, memory consuption is hardly predictable. That makes webhosting e.g. on vservers absolutely impossible, the whole system quickly becomes unstable. IMHO in Pharo there are routines, that really waste a lot of memory, that could be programmed in a more intelligent way, expecially collection's algorithms ... ;-)
Perhaps Donald Knuth books ("Art of Computer Programming") could help? Where e.g. is 'fulltext hash' or 'fulltext search' implemented in Magma, e.t.c.? Whole world works with fulltext databases (Google, MySQL, PostgreSQL, even MSSQL, Oracle). Thats 'state of the art'!!!!!!!! Search in TB databases in milliseconds!
No, latest text searching algorithms aren't in that book. And the world doesn't starts and end in Google and Oracle databases, there are lot of users doing controlled vocabulary searches in commercial or government systems. Cheers, Hernán
so far my 0.0199999999â¬
Keep up the good work on Pharo, it's still a long way to go!
regards, Guido Stepken -- View this message in context: http://n2.nabble.com/Developer-guide-tp4233838p4233838.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, Dec 30, 2009 at 15:15, Guido Stepken <gstepken@googlemail.com>wrote:
2. Interfaces ... hmmm, well ... there are many programmes thinking in categories of "interfaces", "libraries", "class dependencies", e.t.c. Of course, Smalltalk is something completely different, but it makes it difficult for s.b. e.g. coming from Java or C++, to find into Smalltalk concepts. Gofer - till now, i have just a wage imagination, what it's good for ...
Have you looked at Traits?
http://stephane.ducasse.free.fr/Presentations/2009-TraitsAtSC.pdf and much more on Google.
6. Databases: Magma seems to be fine as database, but also dog slow. I really hesitate to start serious projects with Magma.
Take a look at GlorpDBX,
http://n2.nabble.com/ANN-SqueakDBX-Glorp-and-GlorpDBX-loads-easily-in-Pharo-.... This give you support for many RDBMs including Postgres and Oracle.
7. Speed, Memory consumption, Quality of modern algorithms: When working
regards, Guido Stepken -- View this message in context: http://n2.nabble.com/Developer-guide-tp4233838p4233838.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- -JT
On Wed, 30 Dec 2009, Guido Stepken wrote:
1. What classes are compatible to other smalltalks? When i follow mailing-lists of Dolphin, Squeak, VW, VA Magma - there still is a bunch of porting problems. Why?????? What classes should i give preference to minimize porting cost?
Why would you like to port your app?
2. Interfaces ... hmmm, well ... there are many programmes thinking in categories of "interfaces", "libraries", "class dependencies", e.t.c. Of course, Smalltalk is something completely different, but it makes it difficult for s.b. e.g. coming from Java or C++, to find into Smalltalk concepts. Gofer - till now, i have just a wage imagination, what it's good for ...
Reading a book is generally helpful when someone is learning a new language. But it's not necessary with smalltalks since the system is so open that, one can learn by exploring it.
4. Multitasking, green threads, ... There are really missing some pointers, howto code e.g. a background process that is fetching some data from e.g. MySQL or reading/writing large files, sending data over network - without freezing the GUI.
As others pointed out, these are implemented with blocks. What would you do if, say you wanted to know how to do threading in java? Reading a book or googling is helpful: - http://www.google.com/search?q=squeak+threads (I guess a chapter on processes would be useful in PBE/SBE.)
5. Standards: XML-RPC, SOAP, RMI, CORBA, .... encryption (SSL) ... Without having a precise idea, where to find working examples to exchance data with other systems, i would hesitate to begin to do projects with Pharo/Squeak...
Some of this crap is available at squeaksource/squeakmap.
6. Databases: Magma seems to be fine as database, but also dog slow. I really hesitate to start serious projects with Magma.
7. Speed, Memory consumption, Quality of modern algorithms: When working with Seaside, PIER ... that stuff is dog slow, memory consuption is hardly predictable. That makes webhosting e.g. on vservers absolutely impossible, the whole system quickly becomes unstable. IMHO in Pharo there are routines,
Tuning the garbage collector (which one should do when deploying an image) may help here. Btw I didn't experience such problems with seaside (2.8 & 3.0).
that really waste a lot of memory, that could be programmed in a more intelligent way, expecially collection's algorithms ... ;-) Perhaps Donald Knuth books ("Art of Computer Programming") could help?
Can you point out a few examples?
Where e.g. is 'fulltext hash' or 'fulltext search' implemented in Magma, e.t.c.?
What does Magma have to do with Pharo in this context? Where did you read that Magma has full text search? (Btw if you have a data structure that has full text search capabilities then voila, Magma has full text search.)
Whole world works with fulltext databases (Google, MySQL, PostgreSQL, even MSSQL, Oracle). Thats 'state of the art'!!!!!!!! Search in TB databases in milliseconds!
If you need an RDBMS then use one, there are several drivers available. Levente
so far my 0.0199999999ËË
Keep up the good work on Pharo, it's still a long way to go!
regards, Guido Stepken --
Levente, I have to call you out on something: SSL is **definitely** not crap, and we should have a clean interface to it, probably via OpenSSL. I will eventually create same if not beaten to it. CORBA is also not crap. To be blunt, none of the listed technologies are crap if one has an externally defined problem (aka something that pay$ the bill$) that requires communicating with something that uses them. I will grant you that most of them have a pretty high crap coefficient, and I would not go out of my way to use them unless "forced" to do so. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi Sent: Wednesday, December 30, 2009 5:45 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Developer guide ... ? On Wed, 30 Dec 2009, Guido Stepken wrote: [snip] As others pointed out, these are implemented with blocks. What would you do if, say you wanted to know how to do threading in java? Reading a book or googling is helpful: - http://www.google.com/search?q=squeak+threads (I guess a chapter on processes would be useful in PBE/SBE.)
5. Standards: XML-RPC, SOAP, RMI, CORBA, .... encryption (SSL) ... Without having a precise idea, where to find working examples to exchance data with other systems, i would hesitate to begin to do projects with Pharo/Squeak...
Some of this crap is available at squeaksource/squeakmap. Levente
On Wed, 30 Dec 2009, Schwab,Wilhelm K wrote:
Levente,
I have to call you out on something: SSL is **definitely** not crap, and we should have a clean interface to it, probably via OpenSSL. I will eventually create same if not beaten to it.
That's true, I was thinking about the rpc stuff.
CORBA is also not crap. To be blunt, none of the listed technologies are crap if one has an externally defined problem (aka something that pay$ the bill$) that requires communicating with something that uses them. I will grant you that most of them have a pretty high crap coefficient, and I would not go out of my way to use them unless "forced" to do so.
Crap may not be the best word (but fits really well IMO), so overcomplicated bloatware. Levente
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi Sent: Wednesday, December 30, 2009 5:45 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Developer guide ... ?
On Wed, 30 Dec 2009, Guido Stepken wrote:
[snip]
As others pointed out, these are implemented with blocks. What would you do if, say you wanted to know how to do threading in java? Reading a book or googling is helpful: - http://www.google.com/search?q=squeak+threads (I guess a chapter on processes would be useful in PBE/SBE.)
5. Standards: XML-RPC, SOAP, RMI, CORBA, .... encryption (SSL) ... Without having a precise idea, where to find working examples to exchance data with other systems, i would hesitate to begin to do projects with Pharo/Squeak...
Some of this crap is available at squeaksource/squeakmap.
Levente
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Levente, I'll give you a pass on RPC, on SOAP for sure, and _almost_ on CORBA :) However, a culture of dismissing important things as crap lead us to a point approaching 15 years into Squeak's existence where it does not have ready access to SSL. I know about stunnel, but that is more cheat than fix. Pharo needs to embrace the worthy or we will still be on the fringe 15 years from now, and that would be tragic. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi Sent: Wednesday, December 30, 2009 7:14 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Developer guide ... ? On Wed, 30 Dec 2009, Schwab,Wilhelm K wrote:
Levente,
I have to call you out on something: SSL is **definitely** not crap, and we should have a clean interface to it, probably via OpenSSL. I will eventually create same if not beaten to it.
That's true, I was thinking about the rpc stuff.
CORBA is also not crap. To be blunt, none of the listed technologies are crap if one has an externally defined problem (aka something that pay$ the bill$) that requires communicating with something that uses them. I will grant you that most of them have a pretty high crap coefficient, and I would not go out of my way to use them unless "forced" to do so.
Crap may not be the best word (but fits really well IMO), so overcomplicated bloatware. Levente
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi Sent: Wednesday, December 30, 2009 5:45 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Developer guide ... ?
On Wed, 30 Dec 2009, Guido Stepken wrote:
[snip]
As others pointed out, these are implemented with blocks. What would you do if, say you wanted to know how to do threading in java? Reading a book or googling is helpful: - http://www.google.com/search?q=squeak+threads (I guess a chapter on processes would be useful in PBE/SBE.)
5. Standards: XML-RPC, SOAP, RMI, CORBA, .... encryption (SSL) ... Without having a precise idea, where to find working examples to exchance data with other systems, i would hesitate to begin to do projects with Pharo/Squeak...
Some of this crap is available at squeaksource/squeakmap.
Levente
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, 30 Dec 2009, Schwab,Wilhelm K wrote:
Levente,
I'll give you a pass on RPC, on SOAP for sure, and _almost_ on CORBA :) However, a culture of dismissing important things as crap lead us to a point approaching 15 years into Squeak's existence where it does not have ready access to SSL. I know about stunnel, but that is more cheat than fix. Pharo needs to embrace the worthy or we will still be on the fringe 15 years from now, and that would be tragic.
There's an SSL implementation in the Cryptography package, though I don't know if it works or not. If CORBA is so important then why doesn't exist a free smalltalk implementation after 18 years? Levente
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi Sent: Wednesday, December 30, 2009 7:14 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Developer guide ... ?
On Wed, 30 Dec 2009, Schwab,Wilhelm K wrote:
Levente,
I have to call you out on something: SSL is **definitely** not crap, and we should have a clean interface to it, probably via OpenSSL. I will eventually create same if not beaten to it.
That's true, I was thinking about the rpc stuff.
CORBA is also not crap. To be blunt, none of the listed technologies are crap if one has an externally defined problem (aka something that pay$ the bill$) that requires communicating with something that uses them. I will grant you that most of them have a pretty high crap coefficient, and I would not go out of my way to use them unless "forced" to do so.
Crap may not be the best word (but fits really well IMO), so overcomplicated bloatware.
Levente
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi Sent: Wednesday, December 30, 2009 5:45 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Developer guide ... ?
On Wed, 30 Dec 2009, Guido Stepken wrote:
[snip]
As others pointed out, these are implemented with blocks. What would you do if, say you wanted to know how to do threading in java? Reading a book or googling is helpful: - http://www.google.com/search?q=squeak+threads (I guess a chapter on processes would be useful in PBE/SBE.)
5. Standards: XML-RPC, SOAP, RMI, CORBA, .... encryption (SSL) ... Without having a precise idea, where to find working examples to exchance data with other systems, i would hesitate to begin to do projects with Pharo/Squeak...
Some of this crap is available at squeaksource/squeakmap.
Levente
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
You're twisting what I said; I did not put CORBA at the top, I simply acknowledged that it has some value. SSL is useful to the point that I find NO excuse for its not having been wrapped long ago by Sqeuak. The cryptography team _insisted_ on building their own stack vs. using OpenSSL. They managed it; then they burned out. If I have the facts wrong and am missing code, please tell me. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi Sent: Wednesday, December 30, 2009 8:16 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Developer guide ... ? On Wed, 30 Dec 2009, Schwab,Wilhelm K wrote:
Levente,
I'll give you a pass on RPC, on SOAP for sure, and _almost_ on CORBA :) However, a culture of dismissing important things as crap lead us to a point approaching 15 years into Squeak's existence where it does not have ready access to SSL. I know about stunnel, but that is more cheat than fix. Pharo needs to embrace the worthy or we will still be on the fringe 15 years from now, and that would be tragic.
There's an SSL implementation in the Cryptography package, though I don't know if it works or not. If CORBA is so important then why doesn't exist a free smalltalk implementation after 18 years? Levente
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi Sent: Wednesday, December 30, 2009 7:14 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Developer guide ... ?
On Wed, 30 Dec 2009, Schwab,Wilhelm K wrote:
Levente,
I have to call you out on something: SSL is **definitely** not crap, and we should have a clean interface to it, probably via OpenSSL. I will eventually create same if not beaten to it.
That's true, I was thinking about the rpc stuff.
CORBA is also not crap. To be blunt, none of the listed technologies are crap if one has an externally defined problem (aka something that pay$ the bill$) that requires communicating with something that uses them. I will grant you that most of them have a pretty high crap coefficient, and I would not go out of my way to use them unless "forced" to do so.
Crap may not be the best word (but fits really well IMO), so overcomplicated bloatware.
Levente
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi Sent: Wednesday, December 30, 2009 5:45 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Developer guide ... ?
On Wed, 30 Dec 2009, Guido Stepken wrote:
[snip]
As others pointed out, these are implemented with blocks. What would you do if, say you wanted to know how to do threading in java? Reading a book or googling is helpful: - http://www.google.com/search?q=squeak+threads (I guess a chapter on processes would be useful in PBE/SBE.)
5. Standards: XML-RPC, SOAP, RMI, CORBA, .... encryption (SSL) ... Without having a precise idea, where to find working examples to exchance data with other systems, i would hesitate to begin to do projects with Pharo/Squeak...
Some of this crap is available at squeaksource/squeakmap.
Levente
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, 30 Dec 2009, Schwab,Wilhelm K wrote:
You're twisting what I said; I did not put CORBA at the top, I simply acknowledged that it has some value. SSL is useful to the point that I find NO excuse for its not having been wrapped long ago by Sqeuak. The cryptography team _insisted_ on building their own stack vs. using OpenSSL. They managed it; then they burned out. If I have the facts wrong and am missing code, please tell me.
SSL is useful, though most of the time it's used for HTTPS, and we have the cURL plugin to handle that. And you're right, the Cryptography team doesn't exists anymore, the code was abandoned, but the Croquet guys picked it up and fixed a few bugs in it, though it still has some. The code is available here: http://croquet-src-01.oit.duke.edu:8886/Contributions.html (Note that without the DESPlugin the implementation is really slooooooooooow) Levente
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi Sent: Wednesday, December 30, 2009 8:16 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Developer guide ... ?
On Wed, 30 Dec 2009, Schwab,Wilhelm K wrote:
Levente,
I'll give you a pass on RPC, on SOAP for sure, and _almost_ on CORBA :) However, a culture of dismissing important things as crap lead us to a point approaching 15 years into Squeak's existence where it does not have ready access to SSL. I know about stunnel, but that is more cheat than fix. Pharo needs to embrace the worthy or we will still be on the fringe 15 years from now, and that would be tragic.
There's an SSL implementation in the Cryptography package, though I don't know if it works or not. If CORBA is so important then why doesn't exist a free smalltalk implementation after 18 years?
Levente
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi Sent: Wednesday, December 30, 2009 7:14 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Developer guide ... ?
On Wed, 30 Dec 2009, Schwab,Wilhelm K wrote:
Levente,
I have to call you out on something: SSL is **definitely** not crap, and we should have a clean interface to it, probably via OpenSSL. I will eventually create same if not beaten to it.
That's true, I was thinking about the rpc stuff.
CORBA is also not crap. To be blunt, none of the listed technologies are crap if one has an externally defined problem (aka something that pay$ the bill$) that requires communicating with something that uses them. I will grant you that most of them have a pretty high crap coefficient, and I would not go out of my way to use them unless "forced" to do so.
Crap may not be the best word (but fits really well IMO), so overcomplicated bloatware.
Levente
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi Sent: Wednesday, December 30, 2009 5:45 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Developer guide ... ?
On Wed, 30 Dec 2009, Guido Stepken wrote:
[snip]
As others pointed out, these are implemented with blocks. What would you do if, say you wanted to know how to do threading in java? Reading a book or googling is helpful: - http://www.google.com/search?q=squeak+threads (I guess a chapter on processes would be useful in PBE/SBE.)
5. Standards: XML-RPC, SOAP, RMI, CORBA, .... encryption (SSL) ... Without having a precise idea, where to find working examples to exchance data with other systems, i would hesitate to begin to do projects with Pharo/Squeak...
Some of this crap is available at squeaksource/squeakmap.
Levente
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Levente, Please mention curl early and often. However, there are more uses for SSL than just https, and I've already run aground on limitations of the plugin: access to http(s) headers. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi Sent: Wednesday, December 30, 2009 11:12 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Developer guide ... ? On Wed, 30 Dec 2009, Schwab,Wilhelm K wrote:
You're twisting what I said; I did not put CORBA at the top, I simply acknowledged that it has some value. SSL is useful to the point that I find NO excuse for its not having been wrapped long ago by Sqeuak. The cryptography team _insisted_ on building their own stack vs. using OpenSSL. They managed it; then they burned out. If I have the facts wrong and am missing code, please tell me.
SSL is useful, though most of the time it's used for HTTPS, and we have the cURL plugin to handle that. And you're right, the Cryptography team doesn't exists anymore, the code was abandoned, but the Croquet guys picked it up and fixed a few bugs in it, though it still has some. The code is available here: http://croquet-src-01.oit.duke.edu:8886/Contributions.html (Note that without the DESPlugin the implementation is really slooooooooooow) Levente
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi Sent: Wednesday, December 30, 2009 8:16 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Developer guide ... ?
On Wed, 30 Dec 2009, Schwab,Wilhelm K wrote:
Levente,
I'll give you a pass on RPC, on SOAP for sure, and _almost_ on CORBA :) However, a culture of dismissing important things as crap lead us to a point approaching 15 years into Squeak's existence where it does not have ready access to SSL. I know about stunnel, but that is more cheat than fix. Pharo needs to embrace the worthy or we will still be on the fringe 15 years from now, and that would be tragic.
There's an SSL implementation in the Cryptography package, though I don't know if it works or not. If CORBA is so important then why doesn't exist a free smalltalk implementation after 18 years?
Levente
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi Sent: Wednesday, December 30, 2009 7:14 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Developer guide ... ?
On Wed, 30 Dec 2009, Schwab,Wilhelm K wrote:
Levente,
I have to call you out on something: SSL is **definitely** not crap, and we should have a clean interface to it, probably via OpenSSL. I will eventually create same if not beaten to it.
That's true, I was thinking about the rpc stuff.
CORBA is also not crap. To be blunt, none of the listed technologies are crap if one has an externally defined problem (aka something that pay$ the bill$) that requires communicating with something that uses them. I will grant you that most of them have a pretty high crap coefficient, and I would not go out of my way to use them unless "forced" to do so.
Crap may not be the best word (but fits really well IMO), so overcomplicated bloatware.
Levente
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi Sent: Wednesday, December 30, 2009 5:45 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Developer guide ... ?
On Wed, 30 Dec 2009, Guido Stepken wrote:
[snip]
As others pointed out, these are implemented with blocks. What would you do if, say you wanted to know how to do threading in java? Reading a book or googling is helpful: - http://www.google.com/search?q=squeak+threads (I guess a chapter on processes would be useful in PBE/SBE.)
5. Standards: XML-RPC, SOAP, RMI, CORBA, .... encryption (SSL) ... Without having a precise idea, where to find working examples to exchance data with other systems, i would hesitate to begin to do projects with Pharo/Squeak...
Some of this crap is available at squeaksource/squeakmap.
Levente
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
SSL is useful, though most of the time it's used for HTTPS, and we have the cURL plugin to handle that. And you're right, the Cryptography team doesn't exists anymore, the code was abandoned, but the Croquet guys picked it up and fixed a few bugs in it, though it still has some. The code is available here: http://croquet-src-01.oit.duke.edu:8886/Contributions.html (Note that without the DESPlugin the implementation is really slooooooooooow)
thanks for the pointer. May be we should package it again and make it available. Stef
Stef, This would certainly be a good thing to have, but I don't think we should rest until we can work through OpenSSL to benefit from their maintenance efforts. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Thursday, December 31, 2009 5:16 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Developer guide ... ?
SSL is useful, though most of the time it's used for HTTPS, and we have the cURL plugin to handle that. And you're right, the Cryptography team doesn't exists anymore, the code was abandoned, but the Croquet guys picked it up and fixed a few bugs in it, though it still has some. The code is available here: http://croquet-src-01.oit.duke.edu:8886/Contributions.html (Note that without the DESPlugin the implementation is really slooooooooooow)
thanks for the pointer. May be we should package it again and make it available. Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 2009-12-30, at 4:54 PM, Schwab,Wilhelm K wrote:
Levente,
I'll give you a pass on RPC, on SOAP for sure, and _almost_ on CORBA :) However, a culture of dismissing important things as crap lead us to a point approaching 15 years into Squeak's existence where it does not have ready access to SSL. I know about stunnel, but that is more cheat than fix. Pharo needs to embrace the worthy or we will still be on the fringe 15 years from now, and that would be tragic.
Bill
Well someone needs to sit for a week(s) (an oversimplification?) and write the OpenSSL FFI interface. You have funding for that? -- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
I can barely afford not to do it, but it will happen on my own schedule. I will probably also base it on OS threads to achieve non-blocking operation w/o all the BIO* insanity. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John M McIntosh Sent: Wednesday, December 30, 2009 8:49 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Developer guide ... ? On 2009-12-30, at 4:54 PM, Schwab,Wilhelm K wrote:
Levente,
I'll give you a pass on RPC, on SOAP for sure, and _almost_ on CORBA :) However, a culture of dismissing important things as crap lead us to a point approaching 15 years into Squeak's existence where it does not have ready access to SSL. I know about stunnel, but that is more cheat than fix. Pharo needs to embrace the worthy or we will still be on the fringe 15 years from now, and that would be tragic.
Bill
Well someone needs to sit for a week(s) (an oversimplification?) and write the OpenSSL FFI interface. You have funding for that? -- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
John why not call do a call in the seaside mailing-list to see if we could gather some money for that? I think that this is a good to have functionality. Stef On Dec 31, 2009, at 2:49 AM, John M McIntosh wrote:
On 2009-12-30, at 4:54 PM, Schwab,Wilhelm K wrote:
Levente,
I'll give you a pass on RPC, on SOAP for sure, and _almost_ on CORBA :) However, a culture of dismissing important things as crap lead us to a point approaching 15 years into Squeak's existence where it does not have ready access to SSL. I know about stunnel, but that is more cheat than fix. Pharo needs to embrace the worthy or we will still be on the fringe 15 years from now, and that would be tragic.
Bill
Well someone needs to sit for a week(s) (an oversimplification?) and write the OpenSSL FFI interface.
You have funding for that?
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Bill, I think you nailed it precisely! Although all 'systems' working in Pharo will not be enough if we cannot connect and integrate with the leading technologies that we cannot afford to displace/emulate/write in Pharo smalltalk. -- Cesar Rabak Em 30/12/2009 22:54, Schwab,Wilhelm K <bschwab@anest.ufl.edu> escreveu: Levente, I'll give you a pass on RPC, on SOAP for sure, and _almost_ on CORBA :) However, a culture of dismissing important things as crap lead us to a point approaching 15 years into Squeak's existence where it does not have ready access to SSL. I know about stunnel, but that is more cheat than fix. Pharo needs to embrace the worthy or we will still be on the fringe 15 years from now, and that would be tragic. Bill
Cesar, Sometimes rewriting is exactly the right thing to do. For example, Object Arts wrapped the Microsoft XML library. First, there is the question of untrusted input and MS binaries (yikes!!!), but also, any time bad input went into it, it would fire off an error with no indication of where it got into trouble. For some reason, MS did not think to take an IStream pointer that would have allowed one to check the position. For an http client, OA again wrapped MS binaries, complete with the typical punishing timeouts under MS control, and being hobbled if IE had been set (or set itself) to work offline. Dolphin is a wonderful product, but users would have been better served with home-grown code in those cases. Bottom line: I think we should rewrite when it makes sense to do so, and wrap just about anything that makes sense for interoperability. Clearly there is a lot to wrap, and priorities must be set, as it will often fall on an individual to do the dirty work. SSL is a no-brainer. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of csrabak@bol.com.br Sent: Wednesday, December 30, 2009 8:59 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Developer guide ... ? Bill, I think you nailed it precisely! Although all 'systems' working in Pharo will not be enough if we cannot connect and integrate with the leading technologies that we cannot afford to displace/emulate/write in Pharo smalltalk. -- Cesar Rabak Em 30/12/2009 22:54, Schwab,Wilhelm K <bschwab@anest.ufl.edu> escreveu: Levente, I'll give you a pass on RPC, on SOAP for sure, and _almost_ on CORBA :) However, a culture of dismissing important things as crap lead us to a point approaching 15 years into Squeak's existence where it does not have ready access to SSL. I know about stunnel, but that is more cheat than fix. Pharo needs to embrace the worthy or we will still be on the fringe 15 years from now, and that would be tragic. Bill _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/12/31 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Cesar,
Sometimes rewriting is exactly the right thing to do. Â For example, Object Arts wrapped the Microsoft XML library. Â First, there is the question of untrusted input and MS binaries (yikes!!!), but also, any time bad input went into it, it would fire off an error with no indication of where it got into trouble. Â For some reason, MS did not think to take an IStream pointer that would have allowed one to check the position.
For an http client, OA again wrapped MS binaries, complete with the typical punishing timeouts under MS control, and being hobbled if IE had been set (or set itself) to work offline.
I really , see no reason why one would want to wrap such things around. They are so basic, so easy to implement by yourself and not being dependent on crap which comes from MS.
Dolphin is a wonderful product, but users would have been better served with home-grown code in those cases.
Bottom line: I think we should rewrite when it makes sense to do so, and wrap just about anything that makes sense for interoperability. Â Clearly there is a lot to wrap, and priorities must be set, as it will often fall on an individual to do the dirty work. Â SSL is a no-brainer.
Why keep bugging about missing bindings to foo/bar? If you would really need them, you would already implement them by yourself. Event if you are not skilled enough to deal with FFI/primitives stuff, there are a lot of people who do , and can help you with that. Just ask.
Bill
-- Best regards, Igor Stasenko AKA sig.
Bill, Perhaps what I wrote wasn't so clear and I thought I'd put a context when I commented that my ramblings were not about the 'systems' parts which is how I see your observation, and I agree on that. In fact, save some specifics which a plugin makes sense, probably doing in Smalltalk could make the platform more competitive and not only another 'weird syntax' for gluing some other's else libraries. Now, what I was thinking about we have not resources is the big echo systems we need to connect to, for example large packages (ERP/CRM systems), nowadays a hot subject is "Sharepoint integration" but there many others. I believe we should not attempt to write competitive replacements for these as we don't have the resources (not only technical but marketing as well). -- Cesar Rabak Em 31/12/2009 00:17, Schwab,Wilhelm K <bschwab@anest.ufl.edu> escreveu: Cesar, Sometimes rewriting is exactly the right thing to do. For example, Object Arts wrapped the Microsoft XML library. First, there is the question of untrusted input and MS binaries (yikes!!!), but also, any time bad input went into it, it would fire off an error with no indication of where it got into trouble. For some reason, MS did not think to take an IStream pointer that would have allowed one to check the position. For an http client, OA again wrapped MS binaries, complete with the typical punishing timeouts under MS control, and being hobbled if IE had been set (or set itself) to work offline. Dolphin is a wonderful product, but users would have been better served with home-grown code in those cases. Bottom line: I think we should rewrite when it makes sense to do so, and wrap just about anything that makes sense for interoperability. Clearly there is a lot to wrap, and priorities must be set, as it will often fall on an individual to do the dirty work. SSL is a no-brainer. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of csrabak@bol.com.br Sent: Wednesday, December 30, 2009 8:59 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Developer guide ... ? Bill, I think you nailed it precisely! Although all 'systems' working in Pharo will not be enough if we cannot connect and integrate with the leading technologies that we cannot afford to displace/emulate/write in Pharo smalltalk. -- Cesar Rabak Em 30/12/2009 22:54, Schwab,Wilhelm K escreveu: Levente, I'll give you a pass on RPC, on SOAP for sure, and _almost_ on CORBA :) However, a culture of dismissing important things as crap lead us to a point approaching 15 years into Squeak's existence where it does not have ready access to SSL. I know about stunnel, but that is more cheat than fix. Pharo needs to embrace the worthy or we will still be on the fringe 15 years from now, and that would be tragic. Bill _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi levente In VW there is the ObjectMemory class and its policy for doing that. Now what were your setup in Squeak. Passing argument to the vm as parameter or something more elaborated? On Dec 30, 2009, at 11:45 PM, Levente Uzonyi wrote:
Tuning the garbage collector (which one should do when deploying an image) may help here. Btw I didn't experience such problems with seaside (2.8 & 3.0).
Stef
On Thu, 31 Dec 2009, Stéphane Ducasse wrote:
Hi levente
In VW there is the ObjectMemory class and its policy for doing that. Now what were your setup in Squeak. Passing argument to the vm as parameter or something more elaborated?
Just changing vm parameters via SmalltalkImage >> #vmParameterAt:put:. Levente
On Dec 30, 2009, at 11:45 PM, Levente Uzonyi wrote:
Tuning the garbage collector (which one should do when deploying an image) may help here. Btw I didn't experience such problems with seaside (2.8 & 3.0).
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 2009-12-30, at 12:15 PM, Guido Stepken wrote:
7. Speed, Memory consumption,
For a fee I'm always available to do memory consumption tuning, keeping in mind memory consumption is: (a) A result of how the algorithms consume/use memory. (b) The behavior of how the Garbage Collector deals with the garbage in real time. Most programmers can figure out (a), on the other hand (b) can be a very complex task. -- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Guido Stepken <gstepken@...> writes:
Perhaps Donald Knuth books ("Art of Computer Programming") could help? Where e.g. is 'fulltext hash' or 'fulltext search' implemented in Magma, e.t.c.? Whole world works with fulltext databases (Google, MySQL, PostgreSQL, even MSSQL, Oracle). Thats 'state of the art'!!!!!!!! Search in TB databases in milliseconds!
Given Knuth's current speed, he'll approximately gonna cover information retrieval when the Enterprise meets the Klingons. Jokes aside, I implemented a state-of-the-art fulltext search for my master's thesis. It is implemented in VW but should be portable to Squeak. Maintenance of the project has been transfered to the Moose project, so please refer to http://www.moosetechnology.org/tools/vw/hapax for more information. --AA
Guido Stepken wrote:
2. Interfaces ... hmmm, well ... there are many programmes thinking in categories of "interfaces", "libraries", "class dependencies", e.t.c. Of course, Smalltalk is something completely different, but it makes it difficult for s.b. e.g. coming from Java or C++, to find into Smalltalk concepts. Gofer - till now, i have just a wage imagination, what it's good for ...
I have to agree that the whole, project, component, categories, packages, versioning, monticello, metacello thing is still a bit complicated, however I do believe the Pharo team is working hard on this and I think it will get straightened out a bit soon. Guido Stepken wrote:
3. GUI builder. IMHO, it's very easy to build a GUI with morphic. In Squeak, e.g. i simply generate my input forms with EToys, which can be replaced of course by a few lines of code typed in by hand ... But for developers coming from Java, C++ ... the first ask for a GUI builder and XAML e.t.c. There should be some documentation, that leads programmers, that are willing to switch over to Smalltalk, into the right direction. Just a few examples, e.g. how to build a form, that scrolls through some MySQL data sets, really would help. What about compatibility? Is Morphic portable to other Smalltalks?
Assuming you are considering web apps too I would have a look at seaside (which has been ported to a number of smalltalk dialects) or AIDAWeb. From what I understand so far seaside (AIDAWeb will have something similar) has a nice concept of canvas and brushes. It does still lack some sort of nice 4GL GUI WYSIWYG painter .... but I guess you can build one yourself :) Guido Stepken wrote:
6. Databases: Magma seems to be fine as database, but also dog slow. I really hesitate to start serious projects with Magma.
I believe there is more than just Magma though ... how about GOODS, SqueakDBX project, SandstoneDB, GemStone's GLASS ... For a serious (if that refers to big?) project I think you ought to look at GemStone. Guido Stepken wrote:
Keep up the good work on Pharo, it's still a long way to go!
I agree the Pharo team has come a long way in a fairly short time! Go Pharo :) -- View this message in context: http://n2.nabble.com/Developer-guide-tp4233838p4235891.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
participants (13)
-
Adrian Kuhn -
csrabak＠bol.com.br -
Geert Claes -
Guido Stepken -
Hernán Morales Durand -
Igor Stasenko -
John M McIntosh -
John Toohey -
Levente Uzonyi -
Lukas Renggli -
Mariano Martinez Peck -
Schwab,Wilhelm K -
Stéphane Ducasse