Hello, I'm looking how to build GUI app with Pharo and today found out screenshot of Lawsuit Tracker (http://smallworks.eu/web/projects/lawsuit Tracker) which very much resembles 'typical' desktop/business application. The web site says: "It is made using Pharo, Glamour, Magritte and MongoDB." and in my case I'd replace MongoDB with Sqlite3, have need for more grpahical output - something like: http://saravali.de/screenshots.html but wonder about other components and whether they (Glamour/Magritte) are still relevant *today* ? Otoh, today I was re-reading some stuff about Julia language which looks as fine langauge, but it does not fit on one psotcard, although it provides more "classical" way of developing: editor+REPL along with Gtk(.jl) bindings. The language does perform very well, iow. it's quite fast which is good for my project, but it's a bit cumbersome since there is no support to compile end application, while it looks that Pharo has advantage here providing smoother way of deployment (multi-platform wise). Any hint? -- Even if you are considered to be the most sinful of all sinners, when you are situated in the boat of transcendental knowledge you will be able to cross over the ocean of miseries.
Hi, For graphical representation, take a look at Roassal: http://agilevisualization.com Cheers, Doru
On Jan 2, 2016, at 11:51 PM, Saša Janiška <gour@atmarama.com> wrote:
Hello,
I'm looking how to build GUI app with Pharo and today found out screenshot of Lawsuit Tracker (http://smallworks.eu/web/projects/lawsuit Tracker) which very much resembles 'typical' desktop/business application. The web site says: "It is made using Pharo, Glamour, Magritte and MongoDB." and in my case I'd replace MongoDB with Sqlite3, have need for more grpahical output - something like:
http://saravali.de/screenshots.html
but wonder about other components and whether they (Glamour/Magritte) are still relevant *today* ?
Otoh, today I was re-reading some stuff about Julia language which looks as fine langauge, but it does not fit on one psotcard, although it provides more "classical" way of developing: editor+REPL along with Gtk(.jl) bindings.
The language does perform very well, iow. it's quite fast which is good for my project, but it's a bit cumbersome since there is no support to compile end application, while it looks that Pharo has advantage here providing smoother way of deployment (multi-platform wise).
Any hint?
-- Even if you are considered to be the most sinful of all sinners, when you are situated in the boat of transcendental knowledge you will be able to cross over the ocean of miseries.
-- www.tudorgirba.com www.feenk.com "One cannot do more than one can do."
On Ned, 2016-01-03 at 00:07 +0200, Tudor Girba wrote:
For graphical representation, take a look at Roassal: http://agilevisualization.com
Thank. Have to check whether it does fit since my 'drawing' needs are a but unusual. :-) Sincerely, Gour --Â The senses, the mind and the intelligence are the sitting places of this lust. Through them lust covers the real knowledge of the living entity and bewilders him.
there is an an SQlite wrapper for pharo http://forum.world.st/ANN-Updated-SQLite3-wrapper-project-based-on-NB-td4798... the screenshot you shared as Tudor said can be accomplished via Roassal and Morphic. Personally I find the whole performance question kinda irrelevant because if you really want to squeeze the most performance code those parts in C and call them from Pharo via its FFI. Not even Julia will able to outperform that since itself relies on C code for performance and its quite restrictive how you use its dynamic types to achieve high performance. In any case there are always 3 rules, profile, profile and profile. When it comes to performance assume nothing. In the vast majority of cases Pharo JIT VM should be more than enough. And if all you want to do is a business app I dont even know why you worry about performance. Business apps they are very low demand on performance. Pharo libraries dont get irrelevant because the language is so simple it barely changes and the changes usually dont brake compatibility. The only that broke AFAIK is the image format with the new Spur VM but that should not affect libraries. Pharo can do REPL via the playground, the whole deal is that is a lot more than that. GUI wise you can do some pretty awesome stuff with morphic. On Sat, Jan 2, 2016 at 11:53 PM Saša Janiška <gour@atmarama.com> wrote:
Hello,
I'm looking how to build GUI app with Pharo and today found out screenshot of Lawsuit Tracker (http://smallworks.eu/web/projects/lawsuit Tracker) which very much resembles 'typical' desktop/business application. The web site says: "It is made using Pharo, Glamour, Magritte and MongoDB." and in my case I'd replace MongoDB with Sqlite3, have need for more grpahical output - something like:
http://saravali.de/screenshots.html
but wonder about other components and whether they (Glamour/Magritte) are still relevant *today* ?
Otoh, today I was re-reading some stuff about Julia language which looks as fine langauge, but it does not fit on one psotcard, although it provides more "classical" way of developing: editor+REPL along with Gtk(.jl) bindings.
The language does perform very well, iow. it's quite fast which is good for my project, but it's a bit cumbersome since there is no support to compile end application, while it looks that Pharo has advantage here providing smoother way of deployment (multi-platform wise).
Any hint?
-- Even if you are considered to be the most sinful of all sinners, when you are situated in the boat of transcendental knowledge you will be able to cross over the ocean of miseries.
On Sub, 2016-01-02 at 23:27 +0000, Dimitris Chloupis wrote:
there is an an SQlite wrapper for pharoÂ
I know about it. However it would be nice to have some categorized catalog of the packages available for Pharo?
the screenshot you shared as Tudor said can be accomplished via Roassal and Morphic.Â
Now, I'm really a bit puzzled about Roassal' capabilities. :-)
Personally I find the whole performance question kinda irrelevant because if you really want to squeeze the most performance code those parts in C and call them from Pharo via its FFI. Not even Julia will able to outperform that since itself relies on C code for performance and its quite restrictive how you use its dynamic types to achieve high performance.Â
Well, the point is that e.g. I know people who tried to do similar apps in Python and it was too slow, they abandoned it and went to C++. That's the reason why I was primarily exploring statically-compiled languages. Julia *might* be interesting since it is higher-level language with fantastic, close to C performance when one helps compiler by annotating data types. In short, I want to avoid fiddling with low-level languages, otherwise it would be simple to just use C/GTK or C++/Qt. (Java could probably also do the job, but I simply do not like it.) For the most critical part of the application, I anyway plan to use 3rd party C lib which does calculate planetary ephemeris, but for the custom libs using it, I want to use higher-level and type-safer language.
In any case there are always 3 rules, profile, profile and profile. When it comes to performance assume nothing. In the vast majority of cases Pharo JIT VM should be more than enough.Â
Let me see...
And if all you want to do is a business app I dont even know why you worry about performance. Business apps they are very low demand on performance.Â
When I say 'business' app, it is most in the sense of typical 'desktop outlook', while the app itself is falling more into 'science' app, but it depends how one sees astronomy/astrology. :-)
Pharo libraries dont get irrelevant because the language is so simple it barely changes and the changes usually dont brake compatibility.
Pharo's simplicity of the language is huge 'pro'. ;)
Pharo can do REPL via the playground, the whole deal is that is a lot more than that.
Right, it's just that Julia provides more 'traditional' dev work-flow, while with Pharo one has to unwrap one's head a bit. :-)
GUI wise you can do some pretty awesome stuff with morphic.Â
That I still have to learn... Sincerely, Gour --Â A person is said to be elevated in yoga when, having renounced all material desires, he neither acts for sense gratification nor engages in fruitive activities.
Sent from my iPad
On Jan 2, 2016, at 23:57, Saša Janiška <gour@atmarama.com> wrote:
On Sub, 2016-01-02 at 23:27 +0000, Dimitris Chloupis wrote:
there is an an SQlite wrapper for pharo
I know about it.
However it would be nice to have some categorized catalog of the packages available for Pharo?
+1 I find that I just browse the Configuration Browser to see what's out there and then google the name to see if I can find any documentation. And it would be nice to have a wiki like Squeak's.
the screenshot you shared as Tudor said can be accomplished via Roassal and Morphic.
Now, I'm really a bit puzzled about Roassal' capabilities. :-)
Personally I find the whole performance question kinda irrelevant because if you really want to squeeze the most performance code those parts in C and call them from Pharo via its FFI. Not even Julia will able to outperform that since itself relies on C code for performance and its quite restrictive how you use its dynamic types to achieve high performance.
Well, the point is that e.g. I know people who tried to do similar apps in Python and it was too slow, they abandoned it and went to C++.
That's the reason why I was primarily exploring statically-compiled languages. Julia *might* be interesting since it is higher-level language with fantastic, close to C performance when one helps compiler by annotating data types.
In short, I want to avoid fiddling with low-level languages, otherwise it would be simple to just use C/GTK or C++/Qt. (Java could probably also do the job, but I simply do not like it.)
For the most critical part of the application, I anyway plan to use 3rd party C lib which does calculate planetary ephemeris, but for the custom libs using it, I want to use higher-level and type-safer language.
In any case there are always 3 rules, profile, profile and profile. When it comes to performance assume nothing. In the vast majority of cases Pharo JIT VM should be more than enough.
Let me see...
And if all you want to do is a business app I dont even know why you worry about performance. Business apps they are very low demand on performance.
When I say 'business' app, it is most in the sense of typical 'desktop outlook', while the app itself is falling more into 'science' app, but it depends how one sees astronomy/astrology. :-)
Pharo libraries dont get irrelevant because the language is so simple it barely changes and the changes usually dont brake compatibility.
Pharo's simplicity of the language is huge 'pro'. ;)
Pharo can do REPL via the playground, the whole deal is that is a lot more than that.
Right, it's just that Julia provides more 'traditional' dev work-flow, while with Pharo one has to unwrap one's head a bit. :-)
GUI wise you can do some pretty awesome stuff with morphic.
That I still have to learn...
Sincerely, Gour
-- A person is said to be elevated in yoga when, having renounced all material desires, he neither acts for sense gratification nor engages in fruitive activities.
" I know about it. However it would be nice to have some categorized catalog of the packages available for Pharo?" I am considering making such a tool, I call it "Tartara" and it was always in my mind because my project Ephestos is a collections of tools and I wanted package manager that was more sophisticated than Catalog Browser. "Now, I'm really a bit puzzled about Roassal' capabilities. :-)" Roassal is a well design vector graphics API that specializes in data visualisation. "Well, the point is that e.g. I know people who tried to do similar apps in Python and it was too slow, they abandoned it and went to C++. That's the reason why I was primarily exploring statically-compiled languages. Julia *might* be interesting since it is higher-level language with fantastic, close to C performance when one helps compiler by annotating data types. In short, I want to avoid fiddling with low-level languages, otherwise it would be simple to just use C/GTK or C++/Qt. (Java could probably also do the job, but I simply do not like it.) For the most critical part of the application, I anyway plan to use 3rd party C lib which does calculate planetary ephemeris, but for the custom libs using it, I want to use higher-level and type-safer language." The only reason to go C++ is that you want from the first till the last millisecond of your application to have super performance, but if you want to go nuclear performance then languages like CUDA and OpenCL that take advantage of GPUs superior parallelism , provided you do the same calculation over myriads of instances of DATA, will give you easily from 3-100 times faster than C/C++ code execution. So that means you can use something like pyCuda to easily outperform C++. Also tools like cython that offer very close to python syntax can even outperform C/C++ mainly because of the optimizations that VM is doing and the ability to Cython to produce optimised C code. The reality is that pure C++ project become rarer and rarer , for example I use Blender, its 1.4 million lines of code, python is around 13% and if we turn it to equivalent C lines of code it must be around 25% and I suspect another 30% is Cuda / OpenCL, and we talking here about super performance 3d application. Still only 50% is built in C/C++/ObjC. https://www.openhub.net/p?ref=homepage&query=blender In the end its easy to port parts that are not fast to C and call them from Pharo. I remember also that there was a library to use OpenCL from Pharo too. So speed wise you are covered. Pharo even has something similar to cython called Slang that is used to create the Pharo VM. "Right, it's just that Julia provides more 'traditional' dev work-flow, while with Pharo one has to unwrap one's head a bit. :-)" Absolutely and I wont lie to you this definetly increase the learning curve, but frankly it worths it because you come to realize that the traditional way is actually weird and not a very "natural" way of thinking. If C++ is high level, python is higher level then Pharo is highest level language. It maps to the brain completely ignoring the machine architecture. But that takes time to get used to , however if you are interested in such approach I promise you will love pharo. "When I say 'business' app, it is most in the sense of typical 'desktop outlook', while the app itself is falling more into 'science' app, but it depends how one sees astronomy/astrology. :-)" well astrology is not science, astronomy is. An example of a pharo astronomy app is here http://astares.blogspot.gr/2014/04/astrocloud-using-pharo-smalltalk-and.html take also a look at this http://forum.world.st/Pharo-and-Astronomy-tp3027615p3042834.html On Sun, Jan 3, 2016 at 11:12 AM John Pfersich <jpfersich@gmail.com> wrote:
Sent from my iPad
On Jan 2, 2016, at 23:57, Saša Janiška <gour@atmarama.com> wrote:
On Sub, 2016-01-02 at 23:27 +0000, Dimitris Chloupis wrote:
there is an an SQlite wrapper for pharo
I know about it.
However it would be nice to have some categorized catalog of the packages available for Pharo?
+1 I find that I just browse the Configuration Browser to see what's out there and then google the name to see if I can find any documentation.
And it would be nice to have a wiki like Squeak's.
the screenshot you shared as Tudor said can be accomplished via Roassal and Morphic.
Now, I'm really a bit puzzled about Roassal' capabilities. :-)
Personally I find the whole performance question kinda irrelevant because if you really want to squeeze the most performance code those parts in C and call them from Pharo via its FFI. Not even Julia will able to outperform that since itself relies on C code for performance and its quite restrictive how you use its dynamic types to achieve high performance.
Well, the point is that e.g. I know people who tried to do similar apps in Python and it was too slow, they abandoned it and went to C++.
That's the reason why I was primarily exploring statically-compiled languages. Julia *might* be interesting since it is higher-level language with fantastic, close to C performance when one helps compiler by annotating data types.
In short, I want to avoid fiddling with low-level languages, otherwise it would be simple to just use C/GTK or C++/Qt. (Java could probably also do the job, but I simply do not like it.)
For the most critical part of the application, I anyway plan to use 3rd party C lib which does calculate planetary ephemeris, but for the custom libs using it, I want to use higher-level and type-safer language.
In any case there are always 3 rules, profile, profile and profile. When it comes to performance assume nothing. In the vast majority of cases Pharo JIT VM should be more than enough.
Let me see...
And if all you want to do is a business app I dont even know why you worry about performance. Business apps they are very low demand on performance.
When I say 'business' app, it is most in the sense of typical 'desktop outlook', while the app itself is falling more into 'science' app, but it depends how one sees astronomy/astrology. :-)
Pharo libraries dont get irrelevant because the language is so simple it barely changes and the changes usually dont brake compatibility.
Pharo's simplicity of the language is huge 'pro'. ;)
Pharo can do REPL via the playground, the whole deal is that is a lot more than that.
Right, it's just that Julia provides more 'traditional' dev work-flow, while with Pharo one has to unwrap one's head a bit. :-)
GUI wise you can do some pretty awesome stuff with morphic.
That I still have to learn...
Sincerely, Gour
-- A person is said to be elevated in yoga when, having renounced all material desires, he neither acts for sense gratification nor engages in fruitive activities.
On Ned, 2016-01-03 at 09:52 +0000, Dimitris Chloupis wrote:
I am considering making such a tool, I call it "Tartara" and it was always in my mind because my project Ephestos is a collections of tools and I wanted package manager that was more sophisticated than Catalog Browser.
That would be great!
Roassal is a well design vector graphics API that specializes in data visualisation.Â
I'm still not sure whether it can help me with my needs.
The only reason to go C++ is that you want from the first till thelast millisecond of your application to have super performance, but if you want to go nuclear performance then languages like CUDA and OpenCL that take advantage of GPUs superior parallelism
I believe we do not need such stellar performance.
Also tools like cython that offer very close to python syntax can even outperform C/C++ mainly because of the optimizations that VM is doing and the ability to Cython to produce optimised C code.Â
I was considering Cython in the past, but wanted something better than Python...
Absolutely and I wont lie to you this definetly increase the learning curve, but frankly it worths it because you come to realize that the traditional way is actually weird and not a very "natural" way of thinking.
I agree...moreover simplicity of the language is huge factor since it's supposed to be hobby project and I want to have some fun while working on it.
But that takes time to get used to , however if you are interested in such approach I promise you will love pharo.Â
Maybe, as first step I should try to play with NB-FFI to check how working of C lib does work with Pharo...then I can work on providing higher-level API for it and write some Pharo packages on top of it.
well astrology is not science, astronomy is.
Heh, that's only for uninitiated. ;) See:Â http://shyamasundaradasa.com/jyotish/resources/articles/cartoons.ht ml -- It is far better to discharge one's prescribed duties, even though faultily, than another's duties perfectly. Destruction in the course of performing one's own duty is better than engaging in another's duties, for to follow another's path is dangerous.
"Heh, that's only for uninitiated. ;) See: http://shyamasundaradasa.com/jyotish/resources/articles/cartoons.ht ml <http://shyamasundaradasa.com/jyotish/resources/articles/cartoons.html>" The link you provided argues that scientists take things for granted , which is not the case, or that scientists dont understand what electricity is, which is also not the case and that Astronomy has not been proven wrong again and again by science which is also not the case. https://en.wikipedia.org/wiki/Astrology_and_science In any case you are welcomed to believe whatever you want , this is not a philosophy mailing list, just a coding mailing list where only code matters :) On Sun, Jan 3, 2016 at 1:06 PM Saša Janiška <gour@atmarama.com> wrote:
On Ned, 2016-01-03 at 09:52 +0000, Dimitris Chloupis wrote:
I am considering making such a tool, I call it "Tartara" and it was always in my mind because my project Ephestos is a collections of tools and I wanted package manager that was more sophisticated than Catalog Browser.
That would be great!
Roassal is a well design vector graphics API that specializes in data visualisation.
I'm still not sure whether it can help me with my needs.
The only reason to go C++ is that you want from the first till thelast millisecond of your application to have super performance, but if you want to go nuclear performance then languages like CUDA and OpenCL that take advantage of GPUs superior parallelism
I believe we do not need such stellar performance.
Also tools like cython that offer very close to python syntax can even outperform C/C++ mainly because of the optimizations that VM is doing and the ability to Cython to produce optimised C code.
I was considering Cython in the past, but wanted something better than Python...
Absolutely and I wont lie to you this definetly increase the learning curve, but frankly it worths it because you come to realize that the traditional way is actually weird and not a very "natural" way of thinking.
I agree...moreover simplicity of the language is huge factor since it's supposed to be hobby project and I want to have some fun while working on it.
But that takes time to get used to , however if you are interested in such approach I promise you will love pharo.
Maybe, as first step I should try to play with NB-FFI to check how working of C lib does work with Pharo...then I can work on providing higher-level API for it and write some Pharo packages on top of it.
well astrology is not science, astronomy is.
Heh, that's only for uninitiated. ;)
See: http://shyamasundaradasa.com/jyotish/resources/articles/cartoons.ht ml <http://shyamasundaradasa.com/jyotish/resources/articles/cartoons.html>
-- It is far better to discharge one's prescribed duties, even though faultily, than another's duties perfectly. Destruction in the course of performing one's own duty is better than engaging in another's duties, for to follow another's path is dangerous.
there is no Pharo wiki too, but we have plenty of books and documentation that can be found here https://github.com/SquareBracketAssociates On Sun, Jan 3, 2016 at 11:12 AM John Pfersich <jpfersich@gmail.com> wrote:
Sent from my iPad
On Jan 2, 2016, at 23:57, Saša Janiška <gour@atmarama.com> wrote:
On Sub, 2016-01-02 at 23:27 +0000, Dimitris Chloupis wrote:
there is an an SQlite wrapper for pharo
I know about it.
However it would be nice to have some categorized catalog of the packages available for Pharo?
+1 I find that I just browse the Configuration Browser to see what's out there and then google the name to see if I can find any documentation.
And it would be nice to have a wiki like Squeak's.
the screenshot you shared as Tudor said can be accomplished via Roassal and Morphic.
Now, I'm really a bit puzzled about Roassal' capabilities. :-)
Personally I find the whole performance question kinda irrelevant because if you really want to squeeze the most performance code those parts in C and call them from Pharo via its FFI. Not even Julia will able to outperform that since itself relies on C code for performance and its quite restrictive how you use its dynamic types to achieve high performance.
Well, the point is that e.g. I know people who tried to do similar apps in Python and it was too slow, they abandoned it and went to C++.
That's the reason why I was primarily exploring statically-compiled languages. Julia *might* be interesting since it is higher-level language with fantastic, close to C performance when one helps compiler by annotating data types.
In short, I want to avoid fiddling with low-level languages, otherwise it would be simple to just use C/GTK or C++/Qt. (Java could probably also do the job, but I simply do not like it.)
For the most critical part of the application, I anyway plan to use 3rd party C lib which does calculate planetary ephemeris, but for the custom libs using it, I want to use higher-level and type-safer language.
In any case there are always 3 rules, profile, profile and profile. When it comes to performance assume nothing. In the vast majority of cases Pharo JIT VM should be more than enough.
Let me see...
And if all you want to do is a business app I dont even know why you worry about performance. Business apps they are very low demand on performance.
When I say 'business' app, it is most in the sense of typical 'desktop outlook', while the app itself is falling more into 'science' app, but it depends how one sees astronomy/astrology. :-)
Pharo libraries dont get irrelevant because the language is so simple it barely changes and the changes usually dont brake compatibility.
Pharo's simplicity of the language is huge 'pro'. ;)
Pharo can do REPL via the playground, the whole deal is that is a lot more than that.
Right, it's just that Julia provides more 'traditional' dev work-flow, while with Pharo one has to unwrap one's head a bit. :-)
GUI wise you can do some pretty awesome stuff with morphic.
That I still have to learn...
Sincerely, Gour
-- A person is said to be elevated in yoga when, having renounced all material desires, he neither acts for sense gratification nor engages in fruitive activities.
Cool, I haven't seen that resource yet. Thanks for the pointer. I'm currently getting up to speed on graph databases. Sent from my iPad
On Jan 3, 2016, at 01:54, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
there is no Pharo wiki too, but we have plenty of books and documentation that can be found here
https://github.com/SquareBracketAssociates
On Sun, Jan 3, 2016 at 11:12 AM John Pfersich <jpfersich@gmail.com> wrote:
Sent from my iPad
On Jan 2, 2016, at 23:57, Saša Janiška <gour@atmarama.com> wrote:
On Sub, 2016-01-02 at 23:27 +0000, Dimitris Chloupis wrote:
there is an an SQlite wrapper for pharo
I know about it.
However it would be nice to have some categorized catalog of the packages available for Pharo?
+1 I find that I just browse the Configuration Browser to see what's out there and then google the name to see if I can find any documentation.
And it would be nice to have a wiki like Squeak's.
the screenshot you shared as Tudor said can be accomplished via Roassal and Morphic.
Now, I'm really a bit puzzled about Roassal' capabilities. :-)
Personally I find the whole performance question kinda irrelevant because if you really want to squeeze the most performance code those parts in C and call them from Pharo via its FFI. Not even Julia will able to outperform that since itself relies on C code for performance and its quite restrictive how you use its dynamic types to achieve high performance.
Well, the point is that e.g. I know people who tried to do similar apps in Python and it was too slow, they abandoned it and went to C++.
That's the reason why I was primarily exploring statically-compiled languages. Julia *might* be interesting since it is higher-level language with fantastic, close to C performance when one helps compiler by annotating data types.
In short, I want to avoid fiddling with low-level languages, otherwise it would be simple to just use C/GTK or C++/Qt. (Java could probably also do the job, but I simply do not like it.)
For the most critical part of the application, I anyway plan to use 3rd party C lib which does calculate planetary ephemeris, but for the custom libs using it, I want to use higher-level and type-safer language.
In any case there are always 3 rules, profile, profile and profile. When it comes to performance assume nothing. In the vast majority of cases Pharo JIT VM should be more than enough.
Let me see...
And if all you want to do is a business app I dont even know why you worry about performance. Business apps they are very low demand on performance.
When I say 'business' app, it is most in the sense of typical 'desktop outlook', while the app itself is falling more into 'science' app, but it depends how one sees astronomy/astrology. :-)
Pharo libraries dont get irrelevant because the language is so simple it barely changes and the changes usually dont brake compatibility.
Pharo's simplicity of the language is huge 'pro'. ;)
Pharo can do REPL via the playground, the whole deal is that is a lot more than that.
Right, it's just that Julia provides more 'traditional' dev work-flow, while with Pharo one has to unwrap one's head a bit. :-)
GUI wise you can do some pretty awesome stuff with morphic.
That I still have to learn...
Sincerely, Gour
-- A person is said to be elevated in yoga when, having renounced all material desires, he neither acts for sense gratification nor engages in fruitive activities.
On 03 Jan 2016, at 10:11, John Pfersich <jpfersich@gmail.com> wrote:
Sent from my iPad
On Jan 2, 2016, at 23:57, Saša Janiška <gour@atmarama.com> wrote:
On Sub, 2016-01-02 at 23:27 +0000, Dimitris Chloupis wrote:
there is an an SQlite wrapper for pharo
I know about it.
However it would be nice to have some categorized catalog of the packages available for Pharo?
+1 I find that I just browse the Configuration Browser to see what's out there and then google the name to see if I can find any documentation.
you have it: http://catalog.pharo.org <http://catalog.pharo.org/> configuration browser was not good enough so we replaced it in Pharo 5 (packages can be used in older versions, and they are listed in the catalog web page). but again⦠no tool can survive if people does not contribute. Esteban
And it would be nice to have a wiki like Squeak's.
the screenshot you shared as Tudor said can be accomplished via Roassal and Morphic.
Now, I'm really a bit puzzled about Roassal' capabilities. :-)
Personally I find the whole performance question kinda irrelevant because if you really want to squeeze the most performance code those parts in C and call them from Pharo via its FFI. Not even Julia will able to outperform that since itself relies on C code for performance and its quite restrictive how you use its dynamic types to achieve high performance.
Well, the point is that e.g. I know people who tried to do similar apps in Python and it was too slow, they abandoned it and went to C++.
That's the reason why I was primarily exploring statically-compiled languages. Julia *might* be interesting since it is higher-level language with fantastic, close to C performance when one helps compiler by annotating data types.
In short, I want to avoid fiddling with low-level languages, otherwise it would be simple to just use C/GTK or C++/Qt. (Java could probably also do the job, but I simply do not like it.)
For the most critical part of the application, I anyway plan to use 3rd party C lib which does calculate planetary ephemeris, but for the custom libs using it, I want to use higher-level and type-safer language.
In any case there are always 3 rules, profile, profile and profile. When it comes to performance assume nothing. In the vast majority of cases Pharo JIT VM should be more than enough.
Let me see...
And if all you want to do is a business app I dont even know why you worry about performance. Business apps they are very low demand on performance.
When I say 'business' app, it is most in the sense of typical 'desktop outlook', while the app itself is falling more into 'science' app, but it depends how one sees astronomy/astrology. :-)
Pharo libraries dont get irrelevant because the language is so simple it barely changes and the changes usually dont brake compatibility.
Pharo's simplicity of the language is huge 'pro'. ;)
Pharo can do REPL via the playground, the whole deal is that is a lot more than that.
Right, it's just that Julia provides more 'traditional' dev work-flow, while with Pharo one has to unwrap one's head a bit. :-)
GUI wise you can do some pretty awesome stuff with morphic.
That I still have to learn...
Sincerely, Gour
-- A person is said to be elevated in yoga when, having renounced all material desires, he neither acts for sense gratification nor engages in fruitive activities.
Sent from my iPad
On Jan 3, 2016, at 03:49, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 03 Jan 2016, at 10:11, John Pfersich <jpfersich@gmail.com> wrote:
Sent from my iPad
On Jan 2, 2016, at 23:57, Saša Janiška <gour@atmarama.com> wrote:
On Sub, 2016-01-02 at 23:27 +0000, Dimitris Chloupis wrote:
there is an an SQlite wrapper for pharo
I know about it.
However it would be nice to have some categorized catalog of the packages available for Pharo?
+1 I find that I just browse the Configuration Browser to see what's out there and then google the name to see if I can find any documentation.
you have it:
configuration browser was not good enough so we replaced it in Pharo 5 (packages can be used in older versions, and they are listed in the catalog web page). but again⦠no tool can survive if people does not contribute.
Esteban
You should add a link to catalog.pharo.org on the documentation page on Pharo.org. I find it is a very useful tool.
And it would be nice to have a wiki like Squeak's.
the screenshot you shared as Tudor said can be accomplished via Roassal and Morphic.
Now, I'm really a bit puzzled about Roassal' capabilities. :-)
Personally I find the whole performance question kinda irrelevant because if you really want to squeeze the most performance code those parts in C and call them from Pharo via its FFI. Not even Julia will able to outperform that since itself relies on C code for performance and its quite restrictive how you use its dynamic types to achieve high performance.
Well, the point is that e.g. I know people who tried to do similar apps in Python and it was too slow, they abandoned it and went to C++.
That's the reason why I was primarily exploring statically-compiled languages. Julia *might* be interesting since it is higher-level language with fantastic, close to C performance when one helps compiler by annotating data types.
In short, I want to avoid fiddling with low-level languages, otherwise it would be simple to just use C/GTK or C++/Qt. (Java could probably also do the job, but I simply do not like it.)
For the most critical part of the application, I anyway plan to use 3rd party C lib which does calculate planetary ephemeris, but for the custom libs using it, I want to use higher-level and type-safer language.
In any case there are always 3 rules, profile, profile and profile. When it comes to performance assume nothing. In the vast majority of cases Pharo JIT VM should be more than enough.
Let me see...
And if all you want to do is a business app I dont even know why you worry about performance. Business apps they are very low demand on performance.
When I say 'business' app, it is most in the sense of typical 'desktop outlook', while the app itself is falling more into 'science' app, but it depends how one sees astronomy/astrology. :-)
Pharo libraries dont get irrelevant because the language is so simple it barely changes and the changes usually dont brake compatibility.
Pharo's simplicity of the language is huge 'pro'. ;)
Pharo can do REPL via the playground, the whole deal is that is a lot more than that.
Right, it's just that Julia provides more 'traditional' dev work-flow, while with Pharo one has to unwrap one's head a bit. :-)
GUI wise you can do some pretty awesome stuff with morphic.
That I still have to learn...
Sincerely, Gour
-- A person is said to be elevated in yoga when, having renounced all material desires, he neither acts for sense gratification nor engages in fruitive activities.
configuration browser was not good enough so we replaced it in Pharo 5 (packages can be used in older versions, and they are listed in the catalog web page). but again⦠no tool can survive if people does not contribute.
Esteban
You should add a link to catalog.pharo.org <http://catalog.pharo.org> on the documentation page on Pharo.org <http://pharo.org>. I find it is a very useful tool.
I had it in the past and I readd it now ;(
On Ned, 2016-01-03 at 12:49 +0100, Esteban Lorenzano wrote:
you have it:
That's nice, but there are, imho, too many pkgs with "No description provided", so maybe that should be made as mandatory? Sincerely, Gour --Â In the material world, one who is unaffected by whatever good or evil he may obtain, neither praising it nor despising it, is firmly fixed in perfect knowledge.
On 04 Jan 2016, at 11:23, Saša Janiška <gour@atmarama.com> wrote:
On Ned, 2016-01-03 at 12:49 +0100, Esteban Lorenzano wrote:
you have it:
That's nice, but there are, imho, too many pkgs with "No description provided", so maybe that should be made as mandatory?
it is mandatory⦠but people does not provide them, and we could reject the projects, but then they will be irremediable lost. So we took the âleast painâ path. I encourage people to provide correct project descriptions. cheers, Esteban
Sincerely, Gour
-- In the material world, one who is unaffected by whatever good or evil he may obtain, neither praising it nor despising it, is firmly fixed in perfect knowledge.
On 04 Jan 2016, at 12:07, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 04 Jan 2016, at 11:23, Saša Janiška <gour@atmarama.com> wrote:
On Ned, 2016-01-03 at 12:49 +0100, Esteban Lorenzano wrote:
you have it:
That's nice, but there are, imho, too many pkgs with "No description provided", so maybe that should be made as mandatory?
it is mandatory⦠but people does not provide them, and we could reject the projects, but then they will be irremediable lost. So we took the âleast painâ path.
I encourage people to provide correct project descriptions.
I updated a couple of my configs.
cheers, Esteban
Sincerely, Gour
-- In the material world, one who is unaffected by whatever good or evil he may obtain, neither praising it nor despising it, is firmly fixed in perfect knowledge.
I encourage people to provide correct project descriptions.
I updated a couple of my configs.
Good reaction! Stef
cheers, Esteban
Sincerely, Gour
-- In the material world, one who is unaffected by whatever good or evil he may obtain, neither praising it nor despising it, is firmly fixed in perfect knowledge.
I did the same -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jan 5, 2016, at 4:00 PM, stepharo <stepharo@free.fr> wrote:
I updated a couple of my configs.
Good reaction!
On Jan 4, 2016, at 02:23, Saša Janiška <gour@atmarama.com> wrote:
On Ned, 2016-01-03 at 12:49 +0100, Esteban Lorenzano wrote:
you have it:
That's nice, but there are, imho, too many pkgs with "No description provided", so maybe that should be made as mandatory?
And many of the descriptions there aren't terribly descriptive.
Sincerely, Gour
-- In the material world, one who is unaffected by whatever good or evil he may obtain, neither praising it nor despising it, is firmly fixed in perfect knowledge.
And many of the descriptions there aren't terribly descriptive. If people do not value their work.... we cannot do more than what we are doing sadly Stef
Could not agree more Stef It takes no more than 10 minutes to document your project and it's only 2 methods, there are no excuses. Unfortunately you cannot force people to care about their own code. On Tue, 5 Jan 2016 at 09:10, stepharo <stepharo@free.fr> wrote:
And many of the descriptions there aren't terribly descriptive.
If people do not value their work.... we cannot do more than what we are doing sadly
Stef
On 03 Jan 2016, at 08:57, Saša Janiška <gour@atmarama.com> wrote:
On Sub, 2016-01-02 at 23:27 +0000, Dimitris Chloupis wrote:
there is an an SQlite wrapper for pharo
I know about it.
However it would be nice to have some categorized catalog of the packages available for Pharo?
you have the catalog browser (in Pharo 5) and this: http://catalog.pharo.org <http://catalog.pharo.org/> in all the rest. now, if people do not contribute their packages, no tool in the world will help you :) (you contribute your configurations as explained here: http://catalog.pharo.org/catalog/note-for-developers <http://catalog.pharo.org/catalog/note-for-developers>) cheers, Esteban
the screenshot you shared as Tudor said can be accomplished via Roassal and Morphic.
Now, I'm really a bit puzzled about Roassal' capabilities. :-)
Personally I find the whole performance question kinda irrelevant because if you really want to squeeze the most performance code those parts in C and call them from Pharo via its FFI. Not even Julia will able to outperform that since itself relies on C code for performance and its quite restrictive how you use its dynamic types to achieve high performance.
Well, the point is that e.g. I know people who tried to do similar apps in Python and it was too slow, they abandoned it and went to C++.
That's the reason why I was primarily exploring statically-compiled languages. Julia *might* be interesting since it is higher-level language with fantastic, close to C performance when one helps compiler by annotating data types.
In short, I want to avoid fiddling with low-level languages, otherwise it would be simple to just use C/GTK or C++/Qt. (Java could probably also do the job, but I simply do not like it.)
For the most critical part of the application, I anyway plan to use 3rd party C lib which does calculate planetary ephemeris, but for the custom libs using it, I want to use higher-level and type-safer language.
In any case there are always 3 rules, profile, profile and profile. When it comes to performance assume nothing. In the vast majority of cases Pharo JIT VM should be more than enough.
Let me see...
And if all you want to do is a business app I dont even know why you worry about performance. Business apps they are very low demand on performance.
When I say 'business' app, it is most in the sense of typical 'desktop outlook', while the app itself is falling more into 'science' app, but it depends how one sees astronomy/astrology. :-)
Pharo libraries dont get irrelevant because the language is so simple it barely changes and the changes usually dont brake compatibility.
Pharo's simplicity of the language is huge 'pro'. ;)
Pharo can do REPL via the playground, the whole deal is that is a lot more than that.
Right, it's just that Julia provides more 'traditional' dev work-flow, while with Pharo one has to unwrap one's head a bit. :-)
GUI wise you can do some pretty awesome stuff with morphic.
That I still have to learn...
Sincerely, Gour
-- A person is said to be elevated in yoga when, having renounced all material desires, he neither acts for sense gratification nor engages in fruitive activities.
On 03 Jan 2016, at 08:57, Saša Janiška <gour@atmarama.com> wrote:
On Sub, 2016-01-02 at 23:27 +0000, Dimitris Chloupis wrote:
there is an an SQlite wrapper for pharo
I know about it.
However it would be nice to have some categorized catalog of the packages available for Pharo?
the screenshot you shared as Tudor said can be accomplished via Roassal and Morphic.
Now, I'm really a bit puzzled about Roassal' capabilities. :-)
Personally I find the whole performance question kinda irrelevant because if you really want to squeeze the most performance code those parts in C and call them from Pharo via its FFI. Not even Julia will able to outperform that since itself relies on C code for performance and its quite restrictive how you use its dynamic types to achieve high performance.
Well, the point is that e.g. I know people who tried to do similar apps in Python and it was too slow, they abandoned it and went to C++.
for me, that just means they are bad python programmers (and most probably they will not do a good job on C++ either)⦠this thing about performance is a really stablished prejudice⦠but most of the time not true. IMO what you need to do is to build your app and optimise *if needed*, by interfacing with low level/more performant libraries. Esteban
That's the reason why I was primarily exploring statically-compiled languages. Julia *might* be interesting since it is higher-level language with fantastic, close to C performance when one helps compiler by annotating data types.
In short, I want to avoid fiddling with low-level languages, otherwise it would be simple to just use C/GTK or C++/Qt. (Java could probably also do the job, but I simply do not like it.)
For the most critical part of the application, I anyway plan to use 3rd party C lib which does calculate planetary ephemeris, but for the custom libs using it, I want to use higher-level and type-safer language.
In any case there are always 3 rules, profile, profile and profile. When it comes to performance assume nothing. In the vast majority of cases Pharo JIT VM should be more than enough.
Let me see...
And if all you want to do is a business app I dont even know why you worry about performance. Business apps they are very low demand on performance.
When I say 'business' app, it is most in the sense of typical 'desktop outlook', while the app itself is falling more into 'science' app, but it depends how one sees astronomy/astrology. :-)
Pharo libraries dont get irrelevant because the language is so simple it barely changes and the changes usually dont brake compatibility.
Pharo's simplicity of the language is huge 'pro'. ;)
Pharo can do REPL via the playground, the whole deal is that is a lot more than that.
Right, it's just that Julia provides more 'traditional' dev work-flow, while with Pharo one has to unwrap one's head a bit. :-)
GUI wise you can do some pretty awesome stuff with morphic.
That I still have to learn...
Sincerely, Gour
-- A person is said to be elevated in yoga when, having renounced all material desires, he neither acts for sense gratification nor engages in fruitive activities.
Le 2/1/16 22:51, Saša Janiška a écrit :
Hello,
I'm looking how to build GUI app with Pharo and today found out screenshot of Lawsuit Tracker (http://smallworks.eu/web/projects/lawsuit Tracker) which very much resembles 'typical' desktop/business application. The web site says: "It is made using Pharo, Glamour, Magritte and MongoDB." and in my case I'd replace MongoDB with Sqlite3, have need for more grpahical output - something like:
http://saravali.de/screenshots.html
but wonder about other components and whether they (Glamour/Magritte) are still relevant *today* ?
Yes Synectique is building a lot of interfce with Glamour. Yes Magritte is relevant now the Morphic binding may not work. What I can tell you is that Pharo is **really** productive. I suggest you to jump and get the feel for real. Then do an analysis of pro and cons. Doing that in the air is just doing it in the air.
Otoh, today I was re-reading some stuff about Julia language which looks as fine langauge, but it does not fit on one psotcard, although it provides more "classical" way of developing: editor+REPL along with Gtk(.jl) bindings.
The language does perform very well, iow. it's quite fast which is good for my project, but it's a bit cumbersome since there is no support to compile end application, while it looks that Pharo has advantage here providing smoother way of deployment (multi-platform wise).
Any hint?
+1 On Sun, Jan 3, 2016 at 12:32 PM stepharo <stepharo@free.fr> wrote:
Le 2/1/16 22:51, Saša Janiška a écrit :
Hello,
I'm looking how to build GUI app with Pharo and today found out screenshot of Lawsuit Tracker (http://smallworks.eu/web/projects/lawsuit Tracker) which very much resembles 'typical' desktop/business application. The web site says: "It is made using Pharo, Glamour, Magritte and MongoDB." and in my case I'd replace MongoDB with Sqlite3, have need for more grpahical output - something like:
http://saravali.de/screenshots.html
but wonder about other components and whether they (Glamour/Magritte) are still relevant *today* ?
Yes Synectique is building a lot of interfce with Glamour. Yes Magritte is relevant now the Morphic binding may not work.
What I can tell you is that Pharo is **really** productive. I suggest you to jump and get the feel for real. Then do an analysis of pro and cons. Doing that in the air is just doing it in the air.
Otoh, today I was re-reading some stuff about Julia language which looks as fine langauge, but it does not fit on one psotcard, although it provides more "classical" way of developing: editor+REPL along with Gtk(.jl) bindings.
The language does perform very well, iow. it's quite fast which is good for my project, but it's a bit cumbersome since there is no support to compile end application, while it looks that Pharo has advantage here providing smoother way of deployment (multi-platform wise).
Any hint?
On Ned, 2016-01-03 at 11:31 +0100, stepharo wrote:
Yes Synectique is building a lot of interfce with Glamour. Yes Magritte is relevant now the Morphic binding may not work.
Thank you.
What I can tell you is that Pharo is **really** productive. I suggest you to jump and get the feel for real. Then do an analysis of pro and cons. Doing that in the air is just doing it in the air.
That's good advice...I'm a bit reluctant having feeling there are lot of things to learn before really starting, e.g. with some other languages it is very easy to provide call to C libs and explore things, while here it seems that learning curve is steeper...but I'll jump into it. Sincerely, Gour -- A person is considered still further advanced when he regards honest well-wishers, affectionate benefactors, the neutral, mediators, the envious, friends and enemies, the pious and the sinners all with an equal mind.
Hi, On 03/01/16 08:08, Saša Janiška wrote:
What I can tell you is that Pharo is **really** productive. I suggest you to jump and get the feel for real. Then do an analysis of pro and cons. Doing that in the air is just doing it in the air. That's good advice...I'm a bit reluctant having feeling there are lot of things to learn before really starting, e.g. with some other languages it is very easy to provide call to C libs and explore things, while here it seems that learning curve is steeper...but I'll jump into it.
I was in a similar place half an a year ago: https://twitter.com/offrayLC/status/493979407011561473 This is what I'm doing today: https://offray.withknown.com/2016/matrix-sunburst-visualization-example So despite of the culture shock, it has been an excellent joyride! I have never been able to express myself and feel as creative in any other language/environment as with Pharo/Smalltalk. Is a different, but valuable travel to take. Cheers, Offray
For me the journey has been a bit diffirent. Secretely I was always look for a language that think diffirently and followed a more logical approach compared to converved approach of the vast majority of languages that follow C syntax. So I loved the Pharo diffirence. My real struggle was the lack of documentation, I was used to be spoon fed with other languages. My dismay is that many times here I was recommended to start reading pharo code. Suffice to say I was annoyed and frustrated because I was struggling to learn the basics of Pharo and foremost I was more annoyed that people insisted that code readability can replace documentation. Fast forward a couple years later and I have to admit they are kinda correct. Documentation cannot be replaced by code readability for begineers but as I get more and more experienced and familar with pharo and its culture and its libraries the more code I read the less I care about documentation. Unfortunately Pharo code readability is kinda a myth because there is a plenty of code inside pharo that is a huge pain to understand, Auto-completition is one example I struggle for hours and hour to understand and I failed. PharoLauncher is another. But I am getting better and I do believe one day I will be capable enough to read even unreadable pharo code. So I have to say to all those people that insisted that I should learn to read pharo code, thank you, this is indeed a very valuable skill to have. And I will even dare say it more important than documentation because because it does not explain only the what , but also the how and the why, which I think are very important. I completely agree with Esteban, learning a language is an investment. Someone tries Python for a month and finds it slow and goes to C++ , others invest their life implementing a high performance JIT VM like PyPy and create or python features in the language like string manipulation that outperforms C++. In the end its all about the hard work you do with your language and same applies to Pharo as well. Pharo can be used, every where, for anything at any time. Its an incredible useful tool , that inherits a lot of great designs from smalltalk, squeak and improves upon them. Something tells me I may be a pharo user for a long , long time. On Sun, Jan 3, 2016 at 7:52 PM Offray Vladimir Luna Cárdenas < offray@riseup.net> wrote:
Hi,
On 03/01/16 08:08, Saša Janiška wrote:
What I can tell you is that Pharo is **really** productive. I suggest you to jump and get the feel for real. Then do an analysis of pro and cons. Doing that in the air is just doing it in the air. That's good advice...I'm a bit reluctant having feeling there are lot of things to learn before really starting, e.g. with some other languages it is very easy to provide call to C libs and explore things, while here it seems that learning curve is steeper...but I'll jump into it.
I was in a similar place half an a year ago:
https://twitter.com/offrayLC/status/493979407011561473
This is what I'm doing today:
https://offray.withknown.com/2016/matrix-sunburst-visualization-example
So despite of the culture shock, it has been an excellent joyride! I have never been able to express myself and feel as creative in any other language/environment as with Pharo/Smalltalk.
Is a different, but valuable travel to take.
Cheers,
Offray
well, correct link is: http://smallworks.eu/web/projects/lawsuitTracker <http://smallworks.eu/web/projects/lawsuitTracker> I made that app in one month work (just before coming to work in pharo). in one month I managed to: - create Voyage (there was nothing before, and MongoTalk driver was just an experiment not really finished⦠so I needed to finish also the driver⦠for putting an example reading was so slow that after a couple of tweaks a managed to transform a 1s query into a 10ms query⦠just to give you a hint) - tweak glamour to provide better user interactions (often mixing glamour+magritte+glamour inside magritte+more magritte⦠:) - wrap a PDF library (bah, finish a wrapper that already existed, in fact), and a generic âreport toolâ who of course use magritte - create a custom query language âlawyer aptâ (they donât know about sql or databases :P) using petit parser - and learn how to close the image, so an user can have a desktop app without seeing a debugger or a class browser if something happened (errors where directly reported by me using fuel, in the first iteration mariano made, when he was still doing his phd and fuel was still an experimental tool) the application is still in use (by 20+ lawyers in two offices of the same law firm) and they just call me one time in 5 years, and that was because they screw the mongodb installation, not a problem of the application. Can I say Iâm pretty proud of that thingy? :) The main point is that using anything else (I worked in âjava worldâ for 12 years before jumping to Pharo, so I know very well what Iâm talking about) I would take no less than 4 months on doing the same⦠using Pharo and their libraries I managed to do it in one month AND to create something valuable for the community. I would say both glamour and magritte are still fundamental if you want to provide a desktop application⦠even if you have to spend time learning them. Now, about performance, thatâs something always annoys me: people believing this will have a problem before actually having it⦠people believing they will need numbers they do not need. A language like squeak was very capable of having croquet, and a company like this one http://www.3dicc.com <http://www.3dicc.com/> use them to build virtual words and they are very successful. True, they are not second life, and they have some escalation issues, but they manage it pretty well⦠Even high availability games like eveonline are made using python (and not the scripting parts, the full game) and they are capable to handle battles of 3k users in a single instance⦠You think you need better performance than them? Most probably not⦠but even if you need it, I think you are missing the path: you use Pharo and if it happens performance is not enough, then you profile and optimise, probably using some external library: we have FFI and if that is not enough you can always do your own plugins⦠at the end, thatâs what those guys do :) I think is a lot more efficient (and agile) way to create an application⦠in the worst case, you can spend the time you save using Pharo on optimising your solution interfacing with C or whatever. At the end, you will have an application that is a lot more maintainable than using C or C++ as main language. cheers, Esteban
On 02 Jan 2016, at 22:51, Saša Janiška <gour@atmarama.com> wrote:
Hello,
I'm looking how to build GUI app with Pharo and today found out screenshot of Lawsuit Tracker (http://smallworks.eu/web/projects/lawsuit Tracker) which very much resembles 'typical' desktop/business application. The web site says: "It is made using Pharo, Glamour, Magritte and MongoDB." and in my case I'd replace MongoDB with Sqlite3, have need for more grpahical output - something like:
http://saravali.de/screenshots.html
but wonder about other components and whether they (Glamour/Magritte) are still relevant *today* ?
Otoh, today I was re-reading some stuff about Julia language which looks as fine langauge, but it does not fit on one psotcard, although it provides more "classical" way of developing: editor+REPL along with Gtk(.jl) bindings.
The language does perform very well, iow. it's quite fast which is good for my project, but it's a bit cumbersome since there is no support to compile end application, while it looks that Pharo has advantage here providing smoother way of deployment (multi-platform wise).
Any hint?
-- Even if you are considered to be the most sinful of all sinners, when you are situated in the boat of transcendental knowledge you will be able to cross over the ocean of miseries.
participants (9)
-
Alexandre Bergel -
Dimitris Chloupis -
Esteban Lorenzano -
John Pfersich -
Offray Vladimir Luna Cárdenas -
Saša Janiška -
stepharo -
Sven Van Caekenberghe -
Tudor Girba