[Pharo-users] [ANN] MongoTalk, MongoBrowser and Mongo Spotter support

[Torsten Bergmann]

Beside my new article "Building a Mongo Browser in Pharo" [1] and the new 
Mongo Browser tool I now added support for "Spotter browsing/navigation" 
using a running Mongo DB to the project. 

Just load "MongoTalk" from config browser in Pharo 4, run you Mongo database
and then use Spotter to enter a database name.

Attached is a screenshot.

When Mongo is running locally you can easily use spotter now to directly 
browse Mongo databases, included collections and documents of a running 
MongoDB instance. 

If Mongo is not running on localhost you can also switch the default 
db instance:

  Mongo default: (Mongo host: 'myserver' port: 1234)

to browse remotely.

Thx
T.



[1] https://medium.com/@astares/building-a-mongo-browser-in-pharo-fe2104052843

[Pharo-users] Users of Versionner?

[Stephan Eggermont]

Who is actually using Versionner to maintain configurations?
Especially configurations that are used in other configurations?

Stephan

Re: [Pharo-users] Users of Versionner?

[Norbert Hartl]

I do. But only 4 levels deep :)

They are all in http://smalltalkhub.com/#!/~osmocom/Osmocom 


Norbert
> Am 18.03.2015 um 09:46 schrieb Stephan Eggermont :
> 
> Who is actually using Versionner to maintain configurations?
> Especially configurations that are used in other configurations?
> 
> Stephan
> 
> 

Re: [Pharo-users] Users of Versionner?

[Peter Uhnák]

I use(d) it to create groups and specify dependencies - much easier than
writing the spec stuff by hand.

However since I switched to git I would like to also use it for BaselineOf
(which has pretty much the same structure as ConfigurationOf).

Also the "versioning" part is not really needed for git (since git handles
that in branches and tags), but the configuration specification is still
nice.

Peter

On Wed, Mar 18, 2015 at 10:07 AM, Norbert Hartl  wrote:

> I do. But only 4 levels deep :)
>
> They are all in http://smalltalkhub.com/#!/~osmocom/Osmocom
>
> Norbert
>
> Am 18.03.2015 um 09:46 schrieb Stephan Eggermont :
>
> Who is actually using Versionner to maintain configurations?
> Especially configurations that are used in other configurations?
>
> Stephan
>
>
>
>

Re: [Pharo-users] [ANN] MongoTalk, MongoBrowser and Mongo Spotter support

[Tudor Girba]

Nice :)

You are really enjoying yourself.

As an improvement. You could also provide the preview for the database and
collection :).

Cheers,
Doru



On Wed, Mar 18, 2015 at 9:09 AM, Torsten Bergmann  wrote:

> Beside my new article "Building a Mongo Browser in Pharo" [1] and the new
> Mongo Browser tool I now added support for "Spotter browsing/navigation"
> using a running Mongo DB to the project.
>
> Just load "MongoTalk" from config browser in Pharo 4, run you Mongo
> database
> and then use Spotter to enter a database name.
>
> Attached is a screenshot.
>
> When Mongo is running locally you can easily use spotter now to directly
> browse Mongo databases, included collections and documents of a running
> MongoDB instance.
>
> If Mongo is not running on localhost you can also switch the default
> db instance:
>
>   Mongo default: (Mongo host: 'myserver' port: 1234)
>
> to browse remotely.
>
> Thx
> T.
>
>
>
> [1]
> https://medium.com/@astares/building-a-mongo-browser-in-pharo-fe2104052843
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] Users of Versionner?

[Sean P. DeNigris]

Stephan Eggermont wrote
> Who is actually using Versionner to maintain configurations?
> Especially configurations that are used in other configurations?

I use it almost always, only occasionally dropping into the code e.g. for
platform-specific configs



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Users-of-Versionner-tp4812767p4812807.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Users of Versionner?

[Johan Fabry]

I rarely have the need for making or updating configurations. When I do, I use 
it, but only in the most simple way. I still have not figured out completely 
how it works but it easily beats coding all of this by hand! 

> On Mar 18, 2015, at 05:46, Stephan Eggermont  wrote:
> 
> Who is actually using Versionner to maintain configurations?
> Especially configurations that are used in other configurations?
> 
> Stephan
> 
> 
> 



---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile

Re: [Pharo-users] Users of Versionner?

[Guillaume Larcheveque]

I'm using it for Artefact, Telescope and all Synectique's projects

2015-03-18 14:40 GMT+01:00 Johan Fabry :

>
> I rarely have the need for making or updating configurations. When I do, I
> use it, but only in the most simple way. I still have not figured out
> completely how it works but it easily beats coding all of this by hand!
>
> > On Mar 18, 2015, at 05:46, Stephan Eggermont  wrote:
> >
> > Who is actually using Versionner to maintain configurations?
> > Especially configurations that are used in other configurations?
> >
> > Stephan
> >
> >
> >
>
>
>
> ---> Save our in-boxes! http://emailcharter.org <---
>
> Johan Fabry   -   http://pleiad.cl/~jfabry
> PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile
>
>
>


-- 
*Guillaume Larcheveque*

[Pharo-users] Pharo and Pi

[Torsten Bergmann]

Read about "piCore" this week which is a Tiny Core Linux
for the Pi.

As there is 
 - a quick bootable Pharo on top of TinyLinux (Mikes "PharoNOS" project) 
 - a Pharo that is runnable on Pi

I wonder if anyone already did some experiments on booting directly 
into Pharo on a pi. 

Still a "pi newbee" I also would like to know how to get started to
Pharo on Pi. Seems like the CI job is not available:

  https://ci.inria.fr/pharo-contribution/computer/RaspberryPi/ 

Where to get started with Pharo on Pi these days? Any "quick
guide"?

Thx
T.

Re: [Pharo-users] Pharo and Pi

[Mircea]

Count me in too. Just bought two Pi 2s and rand the PharoS VM on top or 
Raspbian OS (linux).

Quick conclusion. Running apps is fine, but optimizations seem lacking somehow 
as it took 30 minutes to install and compile Seaside and it only ever used one 
processor of the Pi 2’s four (quad-core).

The link you have seems to point to some older job.

Try here:
https://ci.inria.fr/pharo-contribution/view/ARM-Raspberry/ 


Check this out for the latest working build:
https://ci.inria.fr/pharo-contribution/view/ARM-Raspberry/job/RaspberryPi-Cross-Compilation/65/
 



> Pe 18 mar. 2015, la 16:35, Torsten Bergmann  a scris:
> 
> Read about "piCore" this week which is a Tiny Core Linux
> for the Pi.
> 
> As there is 
> - a quick bootable Pharo on top of TinyLinux (Mikes "PharoNOS" project) 
> - a Pharo that is runnable on Pi
> 
> I wonder if anyone already did some experiments on booting directly 
> into Pharo on a pi. 
> 
> Still a "pi newbee" I also would like to know how to get started to
> Pharo on Pi. Seems like the CI job is not available:
> 
>  https://ci.inria.fr/pharo-contribution/computer/RaspberryPi/ 
> 
> Where to get started with Pharo on Pi these days? Any "quick
> guide"?
> 
> Thx
> T.
> 

Re: [Pharo-users] Pharo and Pi - FastBltBit

[Mircea]

Also here:

https://ci.inria.fr/pharo-contribution/view/ARM-Raspberry/job/RaspberryPi-Cross-Compilation-FastBltBit/
 


What does FastBltBit mean? Google turns up some results but they are 
inconclusive.



> Pe 18 mar. 2015, la 16:35, Torsten Bergmann  a scris:
> 
> Read about "piCore" this week which is a Tiny Core Linux
> for the Pi.
> 
> As there is 
> - a quick bootable Pharo on top of TinyLinux (Mikes "PharoNOS" project) 
> - a Pharo that is runnable on Pi
> 
> I wonder if anyone already did some experiments on booting directly 
> into Pharo on a pi. 
> 
> Still a "pi newbee" I also would like to know how to get started to
> Pharo on Pi. Seems like the CI job is not available:
> 
>  https://ci.inria.fr/pharo-contribution/computer/RaspberryPi/ 
> 
> Where to get started with Pharo on Pi these days? Any "quick
> guide"?
> 
> Thx
> T.
> 

Re: [Pharo-users] Pharo and Pi

[Sebastian Heidbrink]

Hi Torsten,

we tried to start pharo 4.0 on the Parallella board , which is somehow 
like the Pi2 and did succeed partially.


The problem with Pharo4 and the VM is that there is no NativeBoost nor 
OSProcess available o ARM VMs.


I just strated to do some reseach on this and can't provide more 
information on this but jsut google:

"vm  pharo arm nativeboost Can't find the requested origin"

you can start the image, you can save it, you can load source, but you 
can't use stuff like VirtualGPU yet.


The VMs I tried were all from Inria's jenkins servers.

Sebastian




Am 18.03.2015 um 07:35 schrieb Torsten Bergmann:

Read about "piCore" this week which is a Tiny Core Linux
for the Pi.

As there is
  - a quick bootable Pharo on top of TinyLinux (Mikes "PharoNOS" project)
  - a Pharo that is runnable on Pi

I wonder if anyone already did some experiments on booting directly
into Pharo on a pi.

Still a "pi newbee" I also would like to know how to get started to
Pharo on Pi. Seems like the CI job is not available:

   https://ci.inria.fr/pharo-contribution/computer/RaspberryPi/

Where to get started with Pharo on Pi these days? Any "quick
guide"?

Thx
T.

[Pharo-users] Pharo and Pi

[Torsten Bergmann]

thanks for your answers so far

>we tried to start pharo 4.0 on the Parallella board

OK, but I would like to give the original PI a try. Especially because
there are nice additions like the Tontec mini touch screen, etc.

>The problem with Pharo4 and the VM is that there is no NativeBoost nor 
>OSProcess available o ARM VMs.

Yes NB is x86 so far. Mhh... without OSProcess or NB one can not issue
commands to the underlying system (like Tiny Linux). 

>you can start the image, you can save it, you can load source

At least it is a start and it runs. I guess I would be able to run Teapot at 
least.
So one can use it as a simple Pharo based web (app) serving machine. Right?

Is Filesystem access working (FileBrowser)?

Bye
T.

Re: [Pharo-users] Pharo and Pi

[itli...@schrievkrom.de]

As I posted on my blog yesterday: Pharo 3 is running.

Marten

Am 18.03.2015 um 15:35 schrieb Torsten Bergmann:
> Read about "piCore" this week which is a Tiny Core Linux
> for the Pi.
> 
> As there is 
>  - a quick bootable Pharo on top of TinyLinux (Mikes "PharoNOS" project) 
>  - a Pharo that is runnable on Pi
> 
> I wonder if anyone already did some experiments on booting directly 
> into Pharo on a pi. 
> 
> Still a "pi newbee" I also would like to know how to get started to
> Pharo on Pi. Seems like the CI job is not available:
> 
>   https://ci.inria.fr/pharo-contribution/computer/RaspberryPi/ 
> 
> Where to get started with Pharo on Pi these days? Any "quick
> guide"?
> 
> Thx
> T.
> 


-- 
Marten Feldtmann

Re: [Pharo-users] Users of Versionner?

[stepharo]

I use it but I often code by hand the configurations ;)

Le 18/3/15 09:46, Stephan Eggermont a écrit :

Who is actually using Versionner to maintain configurations?
Especially configurations that are used in other configurations?

Stephan

Re: [Pharo-users] Pharo and Pi

[stepharo]

Our goal is to remove the dependencies to nativeboost.
So we will release Pharo 40 and esteban will work on an FFI to remove NB.

Stef

Le 18/3/15 16:33, Sebastian Heidbrink a écrit :

Hi Torsten,

we tried to start pharo 4.0 on the Parallella board , which is somehow 
like the Pi2 and did succeed partially.


The problem with Pharo4 and the VM is that there is no NativeBoost nor 
OSProcess available o ARM VMs.


I just strated to do some reseach on this and can't provide more 
information on this but jsut google:

"vm  pharo arm nativeboost Can't find the requested origin"

you can start the image, you can save it, you can load source, but you 
can't use stuff like VirtualGPU yet.


The VMs I tried were all from Inria's jenkins servers.

Sebastian




Am 18.03.2015 um 07:35 schrieb Torsten Bergmann:

Read about "piCore" this week which is a Tiny Core Linux
for the Pi.

As there is
  - a quick bootable Pharo on top of TinyLinux (Mikes "PharoNOS" 
project)

  - a Pharo that is runnable on Pi

I wonder if anyone already did some experiments on booting directly
into Pharo on a pi.

Still a "pi newbee" I also would like to know how to get started to
Pharo on Pi. Seems like the CI job is not available:

   https://ci.inria.fr/pharo-contribution/computer/RaspberryPi/

Where to get started with Pharo on Pi these days? Any "quick
guide"?

Thx
T.

[Pharo-users] Pharo and Pi

[Torsten Bergmann]

Stef wrote:
>Our goal is to remove the dependencies to nativeboost.

I know that FFI is now maintained again and there is some initiative
on a (more) unified FFI. Also there may be some issues with NB: harder to 
understand than FFI, not complete for ARM, ...
Also for Apple devices it is not able to generate/perform machine code
in memory. But when you go native you usually have to take care of the
underlying system anyway.

But if I understood correctly all this new improvements/movements away from
NB will be at the cost of performance: FFI will slower than NB. Or did I 
misunderstood? 

The only issues I had with NB so far ist that it initially takes 
some effort to know the details. But it worked great once one get 
used to it and I like that Pharo gets fast with it...

Why not complete 64 bit, AsmJIT/NB for ARM beside x86 and where possible 
provide the NB layer? For other platforms we can fall back to FFI when needed.
For sure there could be a more unified way to call.

Maybe thats the goal of the unified FFI and I just do not know the
details. Maybe NB is already planned as a possible backend and it is
still possible to use it. Or will it be legacy afterwards?

I do not care if it is called "NB" or "FFI" or other, but I would dislike if I 
had 
to give up performance or native possibilities or if we just throw away 
something that was developed/integrated with effort into the image initially.
 
I guess more info or patience is required...

Re: [Pharo-users] Pharo and Pi

[stepharo]

Stef wrote:

Our goal is to remove the dependencies to nativeboost.

I know that FFI is now maintained again and there is some initiative
on a (more) unified FFI. Also there may be some issues with NB: harder to
understand than FFI, not complete for ARM, ...

not working with Spur, not working with 64bits

Also for Apple devices it is not able to generate/perform machine code
in memory. But when you go native you usually have to take care of the
underlying system anyway.

But if I understood correctly all this new improvements/movements away from
NB will be at the cost of performance: FFI will slower than NB. Or did I
misunderstood?

probably in the first period.


The only issues I had with NB so far ist that it initially takes
some effort to know the details. But it worked great once one get
used to it and I like that Pharo gets fast with it...
Me too. But between fast on principle and not working in reality and 
slower and working, I chose the second.

I want Pharo to run on Spur.



Why not complete 64 bit, AsmJIT/NB for ARM beside x86 and where possible
provide the NB layer?
Do you know how to do it? Should we burn months of Esteban to learn it 
so that after he can extend it.

Should we be relying on the knowledge of one single person?


For other platforms we can fall back to FFI when needed.
For sure there could be a more unified way to call.
I spent 14 000 Euros on my budget to pay max as intern to work on 
virtualCPU with igor so that

NB could take advantage of having a CPU abstraction.
They worked great and hard. But NB was never updated to take advantage 
of virtualCPU and probably

virtual CPU was not totally finished.

I thought that Igor would continue to improve NB and use Virtual CPU but 
I was wrong.

To me this is a pure lost of money and max should have worked on updates.

So I learned something: I will not pay interns on projects that I cannot 
use/or maintain myself

I was stupid but I'm learning.



Maybe thats the goal of the unified FFI and I just do not know the
details. Maybe NB is already planned as a possible backend and it is
still possible to use it. Or will it be legacy afterwards?

NB will be a possible backend if
uFFI happens
and if NB works with the system.

So the first step is
use NB syntax for "uFFI front end"
provide FFI as back-end
hope that ronie delivers low end
hope that igor release NB Spur


I do not care if it is called "NB" or "FFI" or other, but I would dislike if I 
had
to give up performance or native possibilities or if we just throw away
something that was developed/integrated with effort into the image initially.


I can tell you that I did my best (and even more) but that this is not 
something that I can control.
If Igor turned into a pumpskin is not my fault or wish. He always got 
all my support (you can ask the team here).

Now there is a lesson in that story: we should not rely on a single person.
  
I guess more info or patience is required...

We want Pharo on Spur!
This is key for clement's works and for all the community.

Stef

Re: [Pharo-users] when iterating over a collection how to determine the current objects index

[stepharo]

so may be we should open a bug entry and make sure that
doWithIndex: is used in the system.
no?

Le 16/3/15 12:19, jtuc...@objektfabrik.de a écrit :

Nicolai,





Am 16.03.15 um 11:59 schrieb Nicolai Hess:


2015-03-14 11:55 GMT+01:00 Sean P. DeNigris >:


Marcus Denker-4 wrote
> which version do we pick? We should pick one, rename the callers

As someone mentioned earlier in the thread, #doWithIndex: has the
advantage
of mirroring the argument order (although this still should be
documented),
and it's the one most people are probably most familiar with, so
IMHO it
makes sense to standardize on that.


I like withIndexDo: because code like


so how would you name the current #do: if you had the choice?

I still think this looks very logical:

#do:
#do:separatedBy:
#doWithIndex:
#doWithSomeOtherSpecialty:andEvenMoreStuff:

And then there still ist the question if the order of the arguments 
should be changed:


today:

do: [:each| ]
doWithIndex: [:each :index| ]

future:

do: [:each| ]
withIndexDo: [:idx :each | ]

Do you really think that is better?

I think that if we move the withIndex part to the beginning of the 
message, it overstates the importance of the fact that we also need 
the index inside the iteration block.





aCollection withIndexDo: aBlock
reads like
"a collection with index"  do

This would make sense if it was a Collection with an Index. If there 
was an IndexedCollection class and maybe some message like 
asIndexedCollection or withIndex, which turns any collection into an 
IndexedCollection. Then the message might be a shortcut for "make thsi 
an indexed collection and iterate over it using its index" - 
comparable to Dictionary>>#keysAndValuesDo: - but please be aware that 
a Dictionary has keys and values by its very own nature. A Collection 
doesn't have an index (other than the fact that the elements are 
stored in some non-guarantueed order).



This may all sound quite picky, but I think this is plain wrong and 
you are about to introduce not only incompatible, but also misleading 
naming for methods that exist on all Smalltalk dialects.


Joachim







-
Cheers,
Sean
--
View this message in context:

http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the-current-objects-index-tp4810920p4811848.html
Sent from the Pharo Smalltalk Users mailing list archive at
Nabble.com.





--
---
Objektfabrik Joachim Tuchelmailto:jtuc...@objektfabrik.de
Fliederweg 1http://www.objektfabrik.de
D-71640 Ludwigsburghttp://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Re: [Pharo-users] when iterating over a collection how to determine the current objects index

[p...@highoctane.be]

Le 16 mars 2015 11:59, "Nicolai Hess"  a écrit :
>
>
> 2015-03-14 11:55 GMT+01:00 Sean P. DeNigris :
>>
>> Marcus Denker-4 wrote
>> > which version do we pick? We should pick one, rename the callers
>>
>> As someone mentioned earlier in the thread, #doWithIndex: has the
advantage
>> of mirroring the argument order (although this still should be
documented),
>> and it's the one most people are probably most familiar with, so IMHO it
>> makes sense to standardize on that.
>
>
> I like withIndexDo: because code like
>
> aCollection withIndexDo: aBlock
> reads like
> "a collection with index"  do
>

I like things ending with do: as they are easy to spot. And you know that
is coming next is a block most of the time.

Not so with doWithIndex:

e.g.

someObject mongoDo: [ ... ].

reads better than

someObject doWithMongo: [ ].

especially when there are things like

mongoDo:
mongoCachedCollectionsDo:
aggregateDo:

and so on.

This is the same story with

... readStreamDo: [  ]

withIndexDo: obeys the principle of least astonishment to me.

Phil

>
>
>
>>
>>
>>
>>
>> -
>> Cheers,
>> Sean
>> --
>> View this message in context:
http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the-current-objects-index-tp4810920p4811848.html
>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>>
>

Re: [Pharo-users] when iterating over a collection how to determine the current objects index

[p...@highoctane.be]

Le 14 mars 2015 12:16, "Sebastian Sastre"  a
écrit :
>
> In such cases I might use a stream and monitor the `stream position` and
iterate with
>
> [ stream atEnd ] whileFalse: [
>   item := stream next.
>   stream position even ifTrue: [ self highlight: item ].
>    ]
>

Exactly!

Streams and collections are perfect for that.

And they can even do:

ReadStream class >> on:from:to:

or upTo: etc.

Phil

> from mobile
>
> > On 10/03/2015, at 09:11, Sanjay Minni  wrote:
> >
> > Hi
> >
> > when iterating over a sequenced collection (array / ordered collection)
how
> > can I determine the current objects index value (without explicitly
storing
> > a counter or looking to match each time)
> >
> > Typically I need it:
> > 1. to display a serial number when printing a report.
> > 2. to determine if I am on the last element.
> > 3. To highlight every n-th element.
> >
> > regards
> > Sanjay
> >
> >
> >
> >
> > -
> > ---
> > Regards, Sanjay
> > --
> > View this message in context:
http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the-current-objects-index-tp4810920.html
> > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> >
>
>

Re: [Pharo-users] Running startup scripts after the UI has finished

[Peter Uhnák]

After a lot of experimenting and unsuccessful attempts to use both defer:
and addDeferredStartupAction: (because I'm probably using it wrong) I ended
up with

[ myCode ] fork

This has not only the wanted behavior of executing after the UI has
rendered, but also doesn't freeze the UI when loading external packages. In
fact the loader itself seems much responsive.

Peter

On Tue, Mar 10, 2015 at 6:45 PM, Esteban Lorenzano 
wrote:

> Smalltalk addDeferredStartupAction: aBlock.
>
> aBlock will be executed after startup, as the comment says:
>
> "Add the monadic or nulladic block to the list of actions that we will be
> performed immediately after the startup is totally executed.”
>
> and
>
> World defer: aBlock
>
> aBlock will be executed in the next UI rendering cycle, as the comment
> DOES NOT says (because is missing) ;)
>
> So I think the first one, or the two combined will give you the solution.
>
> cheers,
> Esteban
>
> > On 10 Mar 2015, at 18:36, Peter Uhnák  wrote:
> >
> > Hi,
> >
> > is it possible to execute startup scripts after the UI has finished
> rendering / the image has loaded?
> >
> > I have install startup script that executes when I create the image,
> however since it starts executing very early the UI is frozen and I don't
> get any progress bar so I don't know what's happening (since I'm
> downloading Roassal and other libraries it can take quite a while.)
> >
> > Thanks,
> > Peter
>
>
>

Re: [Pharo-users] when iterating over a collection how to determine the current objects index

[Johan Fabry]

Actually, using keysAndValuesDo: makes a lot of sense to me and seems to be a 
nice and clean way to resolve this discussion. I really like that it’s nicely 
polymorphic if we consider the keys of a sequenced collection to be the 
indexes. I just like this kind of simplicity … 

> On Mar 18, 2015, at 18:55, Sean P. DeNigris  wrote:
> 
> Lastly, apparently e.g. Dolphin has removed it completely in favor of 
> #keysAndValuesDo: in response to a change in the ANSI standard. From 
> http://forum.world.st/doWithIndex-tp3374968p3374975.html 
>  :
>> #doWithIndex: was in an early ANSI draft, presumably 
>> proposed by one of IBM's representatives but I can't really remember, and we 
>> had it in the version of Dolphin current at the time. Later it was removed 
>> from the standard and replaced with #keysAndValuesDo:, which makes sense 
>> since a sequenced collection can legimitately represent a "keyed collection" 
>> with integer keys. Therefore there is no need for a second enumerator that 
>> does the same thing but with key and value reversed.
> 



---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile

[Pharo-users] Fwd: Re: [ANN] BioSmalltalk

[Offray Vladimir Luna Cárdenas]

 Mensaje reenviado 
Asunto: Re: [Pharo-users] [ANN] BioSmalltalk
Fecha: Wed, 18 Mar 2015 20:53:05 -0500
De: Offray Vladimir Luna Cárdenas 
Para: pharo-us...@lists.gforge.inria.fr

Hi,

I just found this old mail. I know that BioSmalltalk is well and
advancing and I have a friend who works on biocomputing. I Saw the
Google Code page of the project, but as a not-programmer I found
difficult to understand what is the "selling point" of Biosmalltalk for
a biologist...

Anyway I'm just curious about which new experience brings Smalltalk to
old fields. In my own case, making my notebook for data narratives and
visualization has been very enriching and even if there are external
tools in other ecosystems to work on it (pandas, Jupyter, LaTeX), the
integration with them inside a moldable and modifiable tool is hard to beat.

Cheers,

Offray

El 15/03/12 a las 07:32, Hernán Morales Durand escribió:

Dear all,

It's been two years since I've started to work in bioinformatics with
Smalltalk. It has been a difficult decision because the quality and
amount of bioinformatics libraries is absolutely amazing, but I've
received a lot of support from the main researchers at the Institute
of Genetics where I'm working in Argentina.

Now the initial step for a BioSmalltalk release is done. I hope the
FOSS community receive this pre-release as the basis for future
enhacements for bioinformatics with any Smalltalk flavor. Although in
the short-term it is unlikely for a BioSmalltalk to reach the users,
maturity and competitive level of major Bio* toolkits (BioPerl,
BioPython, BioRuby or BioJava), it could take too many years more if I
continue this work alone. However, BioSmalltalk was not conceived to
replace or defeat any other similar packages, but to provide to the
bioinformatics community the features of a pure object system. So feel
free to spread the word for all bioinformaticians, newcomers,
developers, or life scientists, for helping in any way and discovering
why Smalltalk is such a special environment.

This release was implemented in Pharo 1.3 custom Core, but cross
Smalltalk portability was a priority. I'm working now to release
versions for GemStone, Squeak and VisualWorks is there is enough
interest. Everybody is welcome to contribute.

You may download a pre-compiled release from the project page:
http://code.google.com/p/biosmalltalk/

Best regards,

Hernán

[Pharo-users] Logic in Pharo ?

[Alain Busser]

Hello,

I am currently working on mechanical means to solve Aristotle's syllogisms.
My project is here: https://github.com/AlainBusser/LogicGame (programmed in
CoffeeScript for a webApp). When I will present it (in a little more than
two months) I plan to solve the same syllogisms with a software tool which
must be free, of course.

I am thinking about a lightweighted Prolog. Does this exist on Pharo? Or
anything which would be similar (computing in a boolean algebra, something
like alt-ergo etc)...

and, if it runs on Raspbian it will be even better ;-)

Alain

[Pharo-users] Get OS uptime

[Julien Delplanque]

Hi everyone,

I can't find out how to get the uptime of the OS from pharo.

I tried:

(FileLocator root / 'proc' / 'uptime') readStream contents.

and

(FileSystem disk root / 'proc' / 'uptime') readStream contents.

but all what I get is an empty string ''.

I don't know if there are messages in some specific classes to do this
(in OSProcess for example?).

Thanks in advance.

Julien

Re: [Pharo-users] Fwd: Re: [ANN] BioSmalltalk

[Hernán Morales Durand]

Hi Offray,

For a biologist without interest in bioinformatics at all, it would be hard
to "sell" him any Bio* library. They could be better with workflow systems
like Galaxy, MyExperiment, or the Integrated Genome Viewer, etc. biology is
an extremely diversified field, but actually Smalltalk is the perfect
environment for biologists!

To me, a demonstration of the power of BioSmalltalk is the realease of
PhyloclassTalk which I *know* couldn't be possible with Python, Java, Perl,
for a single developer in a short period of time. No matter how many books
and marketing they try to sell, the capability of exploring and debugging
objects in a live environment is unbeatable.

But BioSmalltalk needs desperately other developers. I am open to explain
the internals and boring details to anyone. In the past I tried to talk
with pythonists but that was like talking to a wall, the feeling I
perceived was the environment was so different that they seemed to be
scared. Scared of everything they learnt was not worth it. But the power is
there for everyone, you can inspect a DNA sequence, query for its
properties in a new Inspector, send it to a server and return its
alignment, re-format and serialize, all like using an exploratory data
analysis with observational transformations.

I also tried to BioSmalltalk gets accepted to the Open Bionformatics
Foundation (actually I only requested a page in their wiki for project
visibility & promotion), but **precisely** at the time of my request, they
occurred to implement a new whole policy of project acceptance (but of
course BioRuby, BioJava, BioPerl and BioPython were all in so they were
excluded) and I would have to pay international conference calls to talk
with them(?) about I don't know.

So, the status is the same, but with more objects :). I have added classes
for parsing the Taxonomy Of Life, taxdb, EBI and file formats. I hope to
have the chance to work with the cools project people is releasing in this
community.
Cheers,

Hernán

2015-03-18 23:06 GMT-03:00 Offray Vladimir Luna Cárdenas 
:

>
>
>
>  Mensaje reenviado 
> Asunto: Re: [Pharo-users] [ANN] BioSmalltalk
> Fecha: Wed, 18 Mar 2015 20:53:05 -0500
> De: Offray Vladimir Luna Cárdenas 
> Para: pharo-us...@lists.gforge.inria.fr
>
> Hi,
>
> I just found this old mail. I know that BioSmalltalk is well and
> advancing and I have a friend who works on biocomputing. I Saw the
> Google Code page of the project, but as a not-programmer I found
> difficult to understand what is the "selling point" of Biosmalltalk for
> a biologist...
>
> Anyway I'm just curious about which new experience brings Smalltalk to
> old fields. In my own case, making my notebook for data narratives and
> visualization has been very enriching and even if there are external
> tools in other ecosystems to work on it (pandas, Jupyter, LaTeX), the
> integration with them inside a moldable and modifiable tool is hard to
> beat.
>
> Cheers,
>
> Offray
>
> El 15/03/12 a las 07:32, Hernán Morales Durand escribió:
>
>> Dear all,
>>
>> It's been two years since I've started to work in bioinformatics with
>> Smalltalk. It has been a difficult decision because the quality and
>> amount of bioinformatics libraries is absolutely amazing, but I've
>> received a lot of support from the main researchers at the Institute
>> of Genetics where I'm working in Argentina.
>>
>> Now the initial step for a BioSmalltalk release is done. I hope the
>> FOSS community receive this pre-release as the basis for future
>> enhacements for bioinformatics with any Smalltalk flavor. Although in
>> the short-term it is unlikely for a BioSmalltalk to reach the users,
>> maturity and competitive level of major Bio* toolkits (BioPerl,
>> BioPython, BioRuby or BioJava), it could take too many years more if I
>> continue this work alone. However, BioSmalltalk was not conceived to
>> replace or defeat any other similar packages, but to provide to the
>> bioinformatics community the features of a pure object system. So feel
>> free to spread the word for all bioinformaticians, newcomers,
>> developers, or life scientists, for helping in any way and discovering
>> why Smalltalk is such a special environment.
>>
>> This release was implemented in Pharo 1.3 custom Core, but cross
>> Smalltalk portability was a priority. I'm working now to release
>> versions for GemStone, Squeak and VisualWorks is there is enough
>> interest. Everybody is welcome to contribute.
>>
>> You may download a pre-compiled release from the project page:
>> http://code.google.com/p/biosmalltalk/
>>
>> Best regards,
>>
>> Hernán
>>
>>
>>
>
>
>
>

Re: [Pharo-users] deprecation warning in code critic

[Marcus Denker]

> On 19 Mar 2015, at 00:01, Peter Uhnák  wrote:
> 
> Hi,
> 
> is there a deprecation warning option in the code critic?
> 

only for calls to globals. As code critic analysis statically and does
not even try to do call graph interference (which is hard).

What people sometimes do is to provide specific rules when the deprecrate.

Marcus