> On 03 Jan 2016, at 08:57, Saša Janiška <g...@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. > > > > >
