Re: [Pharo-users] Lawsuit Tracker app

[John Pfersich]

Sent from my iPad

> On Jan 3, 2016, at 03:49, Esteban Lorenzano  wrote:
> 
> 
>> On 03 Jan 2016, at 10:11, John Pfersich  wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> 
 On Jan 2, 2016, at 23:57, Saša Janiška  wrote:
 
 On Sub, 2016-01-02 at 23:27 +, 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
> 
> 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.
> 

Re: [Pharo-users] Spec: Binding widgets how to

[Offray Vladimir Luna Cárdenas]

Thanks again Nicolai! I will start from here :-).

Offray

On 03/01/16 18:20, Nicolai Hess wrote:



2016-01-03 23:52 GMT+01:00 Offray Vladimir Luna Cárdenas 
>:


Hi,

On 03/01/16 08:45, Nicolai Hess wrote:



There is any way to run a minimal GUI with a tree using your
example? I'm still missing a key concept on how to use spec
and binding between widgets.


what is missing ? this is a minimal gui with a tree component.


Ohh, what is missing is not in the example, but in my
understanding on how to use/start it. I would expect for something
like "example openWithSpec" to start deconstructing it, but I'm
still lost about it. I will be working on it today and tomorrow to
see if I can come with better questions.


Ok, for this example you can just start it with:

TreeDemo new openWithSpec

It opens a window with two panes, the upper pane shows a tree with 
some nodes (subclasses of class Morph)
The lower pane shows the text(name) of the selected node. You can 
change and accept (cmd+s) the text in the

lower pane, which will update the name of the tree node.


Cheers,

Offray

[Pharo-users] Using Playgrounds as a notepad

[Andy Burnett]

I often find that I need to do simple manipulations to passages of text,
e.g. remove all carriage returns, or extract email addresses etc.

Pasting the text into a Playground doesn't work because there is always an
apostrophe, or line break or... etc. and the playground complains.

Is there a way to tell a Playground to just ignore the text, and give me a
handle to its contents, so that I can then do something like

playgroundId contents splitOn:Character space.

Alternatively, is there another object that would be more appropriate?
Playground would be really useful just because it is in the menu, and
always available.

Cheers
Andy

Re: [Pharo-users] Spec: Binding widgets how to

[Offray Vladimir Luna Cárdenas]

Hi,

On 03/01/16 08:45, Nicolai Hess wrote:



There is any way to run a minimal GUI with a tree using your
example? I'm still missing a key concept on how to use spec and
binding between widgets.


what is missing ? this is a minimal gui with a tree component.


Ohh, what is missing is not in the example, but in my understanding on 
how to use/start it. I would expect for something like "example 
openWithSpec" to start deconstructing it, but I'm still lost about it. I 
will be working on it today and tomorrow to see if I can come with 
better questions.


Cheers,

Offray

Re: [Pharo-users] Spec: Binding widgets how to

[Nicolai Hess]

2016-01-03 23:52 GMT+01:00 Offray Vladimir Luna Cárdenas 
:

> Hi,
>
> On 03/01/16 08:45, Nicolai Hess wrote:
>
>
>
>
>>
>> There is any way to run a minimal GUI with a tree using your example? I'm
>> still missing a key concept on how to use spec and binding between widgets.
>>
>
> what is missing ? this is a minimal gui with a tree component.
>
>
>
> Ohh, what is missing is not in the example, but in my understanding on how
> to use/start it. I would expect for something like "example openWithSpec"
> to start deconstructing it, but I'm still lost about it. I will be working
> on it today and tomorrow to see if I can come with better questions.
>

Ok, for this example you can just start it with:

TreeDemo new openWithSpec

It opens a window with two panes, the upper pane shows a tree with some
nodes (subclasses of class Morph)
The lower pane shows the text(name) of the selected node. You can change
and accept (cmd+s) the text in the
lower pane, which will update the name of the tree node.



>
> Cheers,
>
> Offray
>

Re: [Pharo-users] Using Playgrounds as a notepad

[Tudor Girba]

Hi,

> On Jan 4, 2016, at 3:21 AM, Andy Burnett  
> wrote:
> 
> I often find that I need to do simple manipulations to passages of text, e.g. 
> remove all carriage returns, or extract email addresses etc. 
> 
> Pasting the text into a Playground doesn't work because there is always an 
> apostrophe, or line break or... etc. and the playground complains.
> 
> Is there a way to tell a Playground to just ignore the text, and give me a 
> handle to its contents, so that I can then do something like
> 
> playgroundId contents splitOn:Character space.
> 
> Alternatively, is there another object that would be more appropriate? 
> Playground would be really useful just because it is in the menu, and always 
> available.

The Playground does not yet allow you to do that. But, you can use the 
Clipboard:

Clipboard clipboardText splitOn:Character space.

Cheers,
Doru

> Cheers
> Andy

--
www.tudorgirba.com
www.feenk.com

"Value is always contextual."

Re: [Pharo-users] Lawsuit Tracker app

[John Pfersich]

Sent from my iPad

> On Jan 2, 2016, at 23:57, Saša Janiška  wrote:
> 
>> On Sub, 2016-01-02 at 23:27 +, 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.
> 
> 
> 
> 
> 

Re: [Pharo-users] Lawsuit Tracker app

[Dimitris Chloupis]

+1

On Sun, Jan 3, 2016 at 12:32 PM stepharo  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?
> >
>
>
>

Re: [Pharo-users] Lawsuit Tracker app

[Saša Janiška]

On Ned, 2016-01-03 at 09:52 +, 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.

Re: [Pharo-users] Lawsuit Tracker app

[Esteban Lorenzano]

well, correct link is: 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  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  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.
> 
> 
> 
> 
> 

Re: [Pharo-users] Lawsuit Tracker app

[Esteban Lorenzano]

> On 03 Jan 2016, at 08:57, Saša Janiška  wrote:
> 
> On Sub, 2016-01-02 at 23:27 +, 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.
> 
> 
> 
> 
> 

Re: [Pharo-users] Lawsuit Tracker app

[Esteban Lorenzano]

> On 03 Jan 2016, at 10:11, John Pfersich  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Jan 2, 2016, at 23:57, Saša Janiška  wrote:
>> 
>>> On Sub, 2016-01-02 at 23:27 +, 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 

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.
>> 
>> 
>> 
>> 
>> 
> 

Re: [Pharo-users] Lawsuit Tracker app

[Dimitris Chloupis]

"
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=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  wrote:

>
>
> Sent from my iPad
>
> > On Jan 2, 2016, at 23:57, Saša Janiška  wrote:
> >
> >> On Sub, 2016-01-02 at 23:27 +, 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, 

Re: [Pharo-users] Lawsuit Tracker app

[John Pfersich]

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  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  wrote:
>> 
>> 
>> Sent from my iPad
>> 
>> > On Jan 2, 2016, at 23:57, Saša Janiška  wrote:
>> >
>> >> On Sub, 2016-01-02 at 23:27 +, 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.
>> >
>> >
>> >
>> >
>> >

Re: [Pharo-users] Lawsuit Tracker app

[stepharo]

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?

Re: [Pharo-users] Lawsuit Tracker app

[Dimitris Chloupis]

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  wrote:

>
>
> Sent from my iPad
>
> > On Jan 2, 2016, at 23:57, Saša Janiška  wrote:
> >
> >> On Sub, 2016-01-02 at 23:27 +, 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.
> >
> >
> >
> >
> >
>
>

Re: [Pharo-users] Lawsuit Tracker app

[Esteban Lorenzano]

> On 03 Jan 2016, at 08:57, Saša Janiška  wrote:
> 
> On Sub, 2016-01-02 at 23:27 +, 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  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 
)

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.
> 
> 
> 
> 
> 

Re: [Pharo-users] Lawsuit Tracker app

[Dimitris Chloupis]

"Heh, that's only for uninitiated. ;)

See: http://shyamasundaradasa.com/jyotish/resources/articles/cartoons.ht
ml "

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  wrote:

> On Ned, 2016-01-03 at 09:52 +, 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.
>
>
>
>
>
>

Re: [Pharo-users] Spec: Binding widgets how to

[Nicolai Hess]

2015-12-23 16:50 GMT+01:00 Offray Vladimir Luna Cárdenas 
:

> Thanks Nicolai for your minimalist example. Only until now I have time to
> test it (sorry), but I get some "MessageNotUnderstood:
> SpecTreeNodeModel>>layoutFrame:" when I run this:
>
> =
> | aClass subItems |
> aClass := RTObject.
> subItems := RTObject subclasses.
> "create the node"
> t :=  TreeNodeModel new
> content: aClass name;
> hasChildren: [ aClass subclasses notEmpty ];
> children: [ subItems ifNil:[subItems:=aClass subclasses collect: [
> :s | self buildNodeFor: s ] ]];
> yourself.
> "listen on selection"
> t whenSelectedChanged: [ :bool | bool ifTrue:[self field text: t content]
> ].
> t openWithSpec
> =
>

The children block codee only works as part of the class I defined with the
method buildNodeFor:
( it calls "self buildNodeFor:")





>
> There is any way to run a minimal GUI with a tree using your example? I'm
> still missing a key concept on how to use spec and binding between widgets.
>

what is missing ? this is a minimal gui with a tree component.


>
> Thanks,
>
> Offray
>
>
> On 29/11/15 13:51, Nicolai Hess wrote:
>
>
>
> 2015-11-26 19:36 GMT+01:00 Offray Vladimir Luna Cárdenas <
> off...@riseup.net>:
>
>> Hi,
>>
>> I had tried that before and didn't work. Passing information between
>> widgets and back in this spec interface seems my stop point now... If
>> someone could help me with some kind of minimalist example that uses
>> treeModel, that would be greatly appreciated.
>>
>
> Find attached a minimal example. (I use Morph and its subclasses for
> generating some tree data, these are just names, renaming a node does not
> rename the class :))
>
> You can listen on tree node selection by registering with
> #whenSelectedChanged, on the TreeNode(!)
>
> "create the node"
> t :=  TreeNodeModel new
> content: aClass name;
> hasChildren: [ aClass subclasses notEmpty ];
> children: [ subItems ifNil:[subItems:=aClass subclasses collect: [
> :s | self buildNodeFor: s ] ]];
> yourself.
>
> "listen on selection"
> t whenSelectedChanged: [ :bool | bool ifTrue:[self field text: t content]
> ].
>
> this will change the text field content with the content of the node (the
> default label).
>
> Changing the label node *Morph* on accepting the text field text is
> somehow impossible or difficult.
> I would have expected that Spec would create a MorphicTreeNodeAdapter that
> represents some Morph, for which the adapter would update/change the state,
> if you change
> the TreeNodeModel content.
> Instead, it creates some strange SpecTreeNodeModel. And the only way to
> update the NodeLabel and make this change visible is to
> rebuild the whole tree:
>
> tree roots: tree roots.
>
> Yes, I did not find another way.
>
> Luckily MorphTreeMorph is smart enough to remember the selection and path
> expansion state, so this works quite well.
>
>
>
>>
>> Cheers,
>>
>> Offray
>>
>>
>> On 26/11/15 12:47, webwarrior wrote:
>>
>>> Try #whenHighlightedItemChanged: method.
>>>
>>> I remember that distinction between selection/highlight is not very
>>> clear in
>>> TreeModel.
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> 
>>> http://forum.world.st/Spec-Binding-widgets-how-to-tp4863742p4863757.html
>>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>>>
>>>
>>>
>>
>>
>
>

Re: [Pharo-users] Lawsuit Tracker app

[Saša Janiška]

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.

Re: [Pharo-users] [IMPORTANT] Starting migration to Spur VM

[EuanM]

I'm happy to help with GUI design stuff.  (I'm formally trained in HCI and in
UI methods, e.g. STUDIO) Simply email me.



--
View this message in context: 
http://forum.world.st/IMPORTANT-Starting-migration-to-Spur-VM-tp4866921p4869102.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

[Pharo-users] Working with a compressed Fuel file?

[Stephan Eggermont]

I'm trying to work with a compressed Fuel file, without having to expand 
everything at the same time. It looks like not all streams are created 
equally. I seem to need a File instead of a FileReference:


saveToFile
|zipStream fileRef|
	fileRef := File named: (FileSystem disk workingDirectory / (self 
fileName, '.zip')) pathString.

fileRef writeStreamDo: [ :s |
zipStream := GZipWriteStream on: s.
repository := nil.
FLSerializer serialize: self on: zipStream.
zipStream close].


And materializing doesn't like this stream

from: aFileName
|zipStream fileRef theNew|
fileRef := File named: aFileName.
fileRef readStreamDo: [ :s |
zipStream := GZipReadStream on: s.
theNew := (FLMaterializer new materializeFrom: zipStream) root.
zipStream close].
^theNew

How am I supposed to work with compressed Fuel files?

Stephan

Re: [Pharo-users] Lawsuit Tracker app

[Offray Vladimir Luna Cárdenas]

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

Re: [Pharo-users] Working with a compressed Fuel file?

[Mariano Martinez Peck]

I may have a hint. Which is the error upon materialization? A dnu on the
stream? Which message?
On Jan 3, 2016 4:19 PM, "Stephan Eggermont"  wrote:

> I'm trying to work with a compressed Fuel file, without having to expand
> everything at the same time. It looks like not all streams are created
> equally. I seem to need a File instead of a FileReference:
>
> saveToFile
> |zipStream fileRef|
> fileRef := File named: (FileSystem disk workingDirectory / (self
> fileName, '.zip')) pathString.
> fileRef writeStreamDo: [ :s |
> zipStream := GZipWriteStream on: s.
> repository := nil.
> FLSerializer serialize: self on: zipStream.
> zipStream close].
>
>
> And materializing doesn't like this stream
>
> from: aFileName
> |zipStream fileRef theNew|
> fileRef := File named: aFileName.
> fileRef readStreamDo: [ :s |
> zipStream := GZipReadStream on: s.
> theNew := (FLMaterializer new materializeFrom: zipStream)
> root.
> zipStream close].
> ^theNew
>
> How am I supposed to work with compressed Fuel files?
>
> Stephan
>
>
>