[Pharo-dev] Ignore this is a test

2016-12-03 Thread stepharo



--
Using Opera's mail client: http://www.opera.com/mail/



[Pharo-dev] how to find projects on github

2016-11-30 Thread stepharo

Hi

I said to nicolas that I should use my super evil power to break iceberg
as requested by him. So I tried.

So I went to github and I typed
iceberg pharo
pharo iceberg
passerini
iceberg
then I browsed pharo-core and related and I could not find anything.

I miss the smalltalkhub.com/list


Stef

--



Re: [Pharo-dev] How to report website text bugs?

2016-11-29 Thread stepharo

On Tue, 29 Nov 2016 00:57:36 +0100, Tim Mackinnon  wrote:


Hi Guys - how is the best way to report website and text bugs?

As I know the English is not always a first language (and you guys are  
busy writing code anyway) - its up to us native English speakers >to  
chip in where we can.


Thank you for this take :)

I was pleased to get the notice that on OSX Sierra I need to do  
something extra to get Pharo to work, however the text could be slightly  
>corrected eg. (Bolded words changed)


Are you using macOS Sierra?
Due to changes in security policies of macOS, you will need to put the  
VM in the  /Applications folder.

We are working to fix this temporary inconvenience.


Also - the Hello world command line example on the front page doesn’t  
work on a standard Terminal on a Mac (you get an error:


$ ./pharo Pharo.image eval "Stdio stdout << 'Hello,World!'"
-bash: !'": event not found


The culprit is of course the “!” Character so a better example might be:



$ ./pharo Pharo.image eval "Stdio stdout << 'Hello World'"

Hello WorldStdioStream: 'stdout'

Although, in this case, is it expected that the return string is merged  
with some other output text >(e.g. the StdioStream:….?). I think its an  
impressive example, but it just doesn’t quite look right?



Tim




--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] two question about fasttable

2016-11-29 Thread stepharo
On Tue, 29 Nov 2016 10:46:09 +0100, Aliaksei Syrel   
wrote:


Called by the table view to return the data object associated with the  
specified row and column.

https://developer.apple.com/reference/appkit/nstableviewdatasource/1533674-tableview



If dataSource does not return view then you are right for the name.
Now in Pharo the name is wrong and may be the design too :)


Cheers,
Alex

On 29 November 2016 at 10:44, Aliaksei Syrel   
wrote:


On 29 November 2016 at 10:39, Esteban Lorenzano   
wrote:

not true.it returns an NSView.


Could you name a method (send a link to a documentation) that is  
implemented by DataSource and returns an NSView?


According to documentation NSView for an item at row/column index is  
created and returned by NSTableView:

https://developer.apple.com/reference/appkit/nstableview/1528831-view

I didn't find any NSView related method in DataSource. Am I looking in  
a wrong place?


Cheers,
Alex






--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] two question about fasttable

2016-11-29 Thread stepharo
On Tue, 29 Nov 2016 09:58:41 +0100, Aliaksei Syrel   
wrote:


"DataSource" is responsible for providing visual elements that represent  
items in a data set.


who said that.
I could say exactly: DataSource is responsible to cut data so that they  
are delivered by row or columns.





I don't see how word "Store" fits here, because DataSource does not  
store anything.


Store in the sense of serving something.

DataSource is also not the best name since it is not a data source  
itself.


Clearly not

An object that is now called DataSource, basically just knows a single  
function that from mathematical point of view can be defined as >follows:

f: Object -> Morph . You see, it is a mapping, not a souse or store.

Cheers,
Alex

On 29 November 2016 at 09:44, Denis Kudriashov   
wrote:



2016-11-29 9:35 GMT+01:00 Esteban Lorenzano :
yes, something like TableCellSource or TableCellProvider is more  
intention revealing.


No, because is not *just* a cell provider.TableDataSource, TableStore,  
TableProvider, yes.


I kind of like “TableStore”.


And if we have TableMorph then this guy should be TableMorphStore IMO.






--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] two question about fasttable

2016-11-29 Thread stepharo




No, because is not *just* a cell provider.TableDataSource, TableStore,  
TableProvider, yes.


I kind of like “TableStore”.Also we have other stores in image:  
FileSystem stores… which conceptually do more or less the same… so  
better to unify concepts/>names… what do you think?


TableMorphStore?
Because I was really shocked to see that it returned Morph.





Esteban



Christophe






--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] two question about fasttable

2016-11-29 Thread stepharo





- Then I miss an important design point. Why datasource returns  
Morph?
I do not get get why a data source should return UI element. To me it  
violates layers.


no, because that’s its purpose: to provide the table with the cell  
elements (which are by definition Morphs… any kind of >>>morphs).a  
TableDataSource is not a spec, is the provider of cells.





so maybe TableCellSource / TableCellProvider ?


I’m not against changing its name, in general the family of names are  
“DataSource”, “Store”, etc. so I imagine that “Provider” fits (even if I  
>tend to hate names style “Manager”, “Factory”, “Provider”, because  
there are too generic… sometimes is that what you have :P)
But is not just a “cell provider”, it does something more, is a general  
model of the TableMorph: it provides cells, headers and interaction  
>capabilities (like drag&drop)… so it is more like a "table data  
provider”, TableDataSource, TableStore, TableProvider are then better  
>names, IMO…


Please please please.
So I was always confused.




this changes will impact Pharo 7… is very good that we can have a  
discussion like this now, that we have the time to reach a consensus >:)


Esteban



cheers -ben






--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] two question about fasttable

2016-11-29 Thread stepharo
On Mon, 28 Nov 2016 22:29:08 +0100, Esteban Lorenzano  
 wrote:



Hi,

On 28 Nov 2016, at 21:32, stepharo  wrote:

Hi

- Could we rename FastTable into Table?


not for Pharo 6 but Pharo 7 yes… in fact, I think it should be called  
TableMorph.

(Also we need to refactor a lot, to eliminate the FT prefix, etc.)



- Then I miss an important design point. Why datasource returns Morph?
I do not get get why a data source should return UI element. To me it  
violates layers.


no, because that’s its purpose: to provide the table with the cell  
elements (which are by definition Morphs… any kind of morphs).a  
TableDataSource is not a spec, is the provider of cells.


What a ugly name then...
Why this is not a CellMorphFactory or something like that.




I got inspired for Cocoa NSTableView design (and NSTableViewDataSource),  
and that’s what it does.See for example here:  
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/TableView/PopulatingView->TablesProgrammatically/PopulatingView-TablesProgrammatically.html

This function: >- (NSView *)tableView:(NSTableView *)tableView
  viewForTableColumn:(NSTableColumn *)tableColumn
 row:(NSInteger)row




is the equivalent of our FTDataSource>>cellColumn:row:

Esteban



Stef



--Using Opera's mail client: http://www.opera.com/mail/







--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] two question about fasttable

2016-11-29 Thread stepharo

Ok so I never understand it that way.
What a bad name.

Stef



On 28 Nov 2016, at 22:25, Henrik Nergaard   
wrote:


The datasource is a wrapper/binding between the real object and the  
view (table/list) and provides the necessary stuff for >>display and  
interaction between them. Returning custom UI elements (cells and rows)  
from the datasource is part of what >>makes it possible to reuse the  
same table/container morph for lists/tables/trees.


this ^ :)

Esteban





--
Using Opera's mail client: http://www.opera.com/mail/

[Pharo-dev] two question about fasttable

2016-11-28 Thread stepharo

Hi

- Could we rename FastTable into Table?

- Then I miss an important design point. Why datasource returns Morph?
I do not get get why a data source should return UI element. To me it  
violates layers.


Stef



--
Using Opera's mail client: http://www.opera.com/mail/



Re: [Pharo-dev] [Vm-dev] Removing most of the windowing code

2016-11-27 Thread stepharo
On Sat, 26 Nov 2016 23:16:50 +0100, Ronie Salgado   
wrote:



Hi,

I am fighting Window VM compilation issues (e.g. Cairo with GCC5.x  
under Mingw).
If you have a GCC5 instead of the old 4.6, I am interested in your  
config.
Now I am building in Windows using both, MinGW version 4.9.3, and Visual  
Studio 2015 Community Edition.


I got working pharo,exe -headless Pharo-minimal.image eval "1+1" (the  
-headless parameter is for the image to quit after finishing).
When running a normal Pharo.image, I am getting a FFI related crash  
(with Visual Studio and MinGW), when the image tries to read the APPDATA  
environment variable.


Right now I am using the same main function for both, the Unix and Win32  
VM. This means, that we are close of having the embedded version.



I love that :)



In windows I am build two variants of the VM, pharo.exe (or squeak.exe)  
and pharow.exe (or squeakw.exe). The executable without the w is a  
console program, so it can >use stdin, stdout and stderr. The executable  
with the w is a windows program that does not create a console window on  
startup, but it cannot use stdout, stderr, or stdin. >This is the  
standard workaround for an annoying limitation of Windows itself (Python  
does the same in windows, with the same nomenclature).


Yes this is on the roadmap of esteban but he got killed by vm merge + UFFI



Visual Studio is unstable than MinGW, but it has an excellent debugger.  
With Visual Studio, I am getting some false positives for an assertion  
because they get >miscompiled. For some reason, the  
assert(GIV(remapBufferCount) == 0) gets compiled into the same as  
assert(GIV(remapBufferCount)). Apart from this assertion, these >two  
versions of the VM are crashing in the same place.




Fantastic, except:



- Unified standard CMake building scripts for Unixes. I hate autoconf.  
I want to use them in Windows too.


We have agreed that we will use makefiles and restrict make to  
generating platform config.h files that define platform facilities.  I  
have very good reasons for doing this.  I >>have discussed this at  
length this year.  Please don't make me argue this all over again.

...
[goodness deleted]
I cannot just use makefile, because I am also compiling in Windows using  
Visual Studio 2015 Community Edition, by generating the visual studio  
projects with CMake. I >looked for the older discussions on the mailing  
lists, I could not find, a long discussion on the mailing list, except  
for several short ones.
I have also seen some projects(LLVM, Boost) that have more than one  
build system, an official based on autoconf(or something else), and an  
alternative based on CMake.


As for the config.h, I can also generate it using CMake, and I will  
start doing it now because I think that it is related to the FFI  
crashing issues that I am experimenting on >Windows. Currently I am  
already using CMake for generating the git version string. As long as  
git is in the path and cmake founds it, the header with the version  
string is >generated correctly, even when using the Visual Studio  
projects.


Anyway, I am not using the old CMakeVMMaker that Igor did(and I just  
learned about Ian CMake work by finding in the mailing list). I just  
adapted the plain CMake scripts >that I normally use for building my own  
projects to build the VM.


 Are you on board?  Would you like to discuss this on skype or  
somewhere?
Sure we can discuss it, I am on chile so we are not far apart in time  
zones.


As long as building the VM can be done automatically in Unixes by  
running a short number of commands, that work most of the time, I am OK  
with it.
As for Windows, it has to be possible to use Visual Studio in addition  
to MinGW or Cygwin. Visual Studio is required to be able to build for  
the Universal Windows Platform, >and getting the VM working in a retail  
XBox One ( https://msdn.microsoft.com/en-us/windows/uwp/xbox-apps/index  
).


Best regards,
Ronie

2016-11-26 14:09 GMT-03:00 Eliot Miranda :

Hi Roni,


On Nov 23, 2016, at 11:12 PM, Ronie Salgado  wrote:


Hello,

I am working on removing most of windowing code from the VM, and in  
trying to unify the platform specific code of the VM. In the  
MinimalistHeadless >>>branch of  
https://github.com/ronsaldo/opensmalltalk-vm I made the following  
changes:


Fantastic, except:



- Unified standard CMake building scripts for Unixes. I hate autoconf.  
I want to use them in Windows too.


We have agreed that we will use makefiles and restrict make to  
generating platform config.h files that define platform facilities.  I  
have very good reasons for doing this.  I >>have discussed this at  
length this year.  Please don't make me argue this all over again.  Are  
you on board?  Would you like to discuss this on skype or somewhere?

...
[goodness deleted]

Does it make sense, to always trying to create a display in startup  
time?


Good question.  The answer should be "no" but that only makes

[Pharo-dev] Is extract method still working?

2016-11-26 Thread stepharo

Hi

on this expression when I select

KeyedTree new
at: 1 put: '1-3-1';
at: 2 put: '1-3-2';
yourself

I get an error because the method extracted look like the following.

at: 1 put: '1-3-1';
at: 2 put: '1-3-2';
yourself

testSubtrees
"Test the subtrees method for success and failure modes."

| t1 t2 t3 t4 |
t1 := KeyedTree new
at: 1
put:
(t2 := KeyedTree new
at: 1 put: '1-1';
at: 2 put: '1-2';
at: 3
put:
(t3 := KeyedTree new
at: 1 put: '1-3-1';
at: 2 put: '1-3-2';
yourself);
yourself);
at: 2 put: '2';
at: 3
put:
(t4 := KeyedTree new
at: 1 put: '1-3-1';
at: 2 put: '1-3-2';
yourself);
yourself.

I wonder if something change in the AST.


--



Re: [Pharo-dev] LinkedList>>#containsCycle

2016-11-26 Thread stepharo

Hi doru


Hi Stef,

Would it make sense to put the collection extensions from Moose in the  
Container project?


If you think it make sense. Yes.

For example Ropes could be managed there.
Have a look I have tiny packages.
The idea is to make sure that
	- people can use one abstraction and not be forced to load a complete  
library

- document them with tests and others
	- gather most of collections in one place to make sure that we do not  
lose energy reimplementing them.


I'm packaging the collection from the image that have no users in the  
image for now.

Then I will continue to package
a Tree package (I tried to contact his author but may be he passed away)
SkipList
Quadtrees.

Stef



Cheers,
Doru



On Nov 26, 2016, at 12:11 PM, stepharo  wrote:

Hi Sven

I'm collecting alternative Collection implementations in the project  
Container

I do not remember if I have linkedList but we can add it there.

You may wonder why I'm doing that?
	- I want to be able to have strong collections that are independent  
from the kernel
	- Ideally the kernel of Pharo should be mininmal so it means that I  
would like to

have as few as possible as collections inside the bootstrapped kernel
and that other collections are nicely packaged in Container.

Now I can understand that others do not like what I'm doing but I will  
just continue.

I have Grid, LinkedList, DoubleLinkedList,
I have on my disc
two implementation of Trees
I should harvest BTrees and SkipList.

If people want to help they are welcome, else I will just do it alone.

Stef


Hi,

There exists a very elegant algorithm to detect cycles in linked lists.

 https://en.wikipedia.org/wiki/Cycle_detection#Tortoise_and_hare

I know that our LinkedList was written with the assumption that there  
are no cycles. However, it seems to me that it would be nice to have a  
test to check for cycles. This could be useful while printing or  
inspecting a LinkedList (and prevent things from blowing up when there  
is a cycle).


Here is the implementation:

LinkedList>>#containsCycle
 | slow fast |
 slow := fast := firstLink.
 [ slow notNil and: [ fast notNil and: [ fast nextLink notNil ] ] ]
   whileTrue: [
 slow := slow nextLink.
 fast := fast nextLink nextLink.
 slow == fast
   ifTrue: [ ^ true ] ].
 ^ false

And one of the tests:

LinkedListTests>>#testCycles
 1 to: 42 do: [ :each |
   list := LinkedList withAll: (1 to: each).
   "Warning: the following statement creates a cylce,
inspecting/viewing list will probably fail"
   list lastLink nextLink: list firstLink.
   self assert: list containsCycle ]

Opinions ?

Sven





--
Using Opera's mail client: http://www.opera.com/mail/



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

"Not knowing how to do something is not an argument for how it cannot be  
done."






--
Using Opera's mail client: http://www.opera.com/mail/



Re: [Pharo-dev] LinkedList>>#containsCycle

2016-11-26 Thread stepharo

I added to the CT package


Hi,

There exists a very elegant algorithm to detect cycles in linked lists.

  https://en.wikipedia.org/wiki/Cycle_detection#Tortoise_and_hare

I know that our LinkedList was written with the assumption that there  
are no cycles. However, it seems to me that it would be nice to have a  
test to check for cycles. This could be useful while printing or  
inspecting a LinkedList (and prevent things from blowing up when there  
is a cycle).


Here is the implementation:

LinkedList>>#containsCycle
  | slow fast |
  slow := fast := firstLink.
  [ slow notNil and: [ fast notNil and: [ fast nextLink notNil ] ] ]
whileTrue: [
  slow := slow nextLink.
  fast := fast nextLink nextLink.
  slow == fast
ifTrue: [ ^ true ] ].
  ^ false

And one of the tests:

LinkedListTests>>#testCycles
  1 to: 42 do: [ :each |
list := LinkedList withAll: (1 to: each).
"Warning: the following statement creates a cylce,
 inspecting/viewing list will probably fail"
list lastLink nextLink: list firstLink.
self assert: list containsCycle ]

Opinions ?

Sven





--
Using Opera's mail client: http://www.opera.com/mail/



Re: [Pharo-dev] LinkedList>>#containsCycle

2016-11-26 Thread stepharo

Hi Sven

I'm collecting alternative Collection implementations in the project  
Container

I do not remember if I have linkedList but we can add it there.

You may wonder why I'm doing that?
	- I want to be able to have strong collections that are independent from  
the kernel
	- Ideally the kernel of Pharo should be mininmal so it means that I would  
like to

have as few as possible as collections inside the bootstrapped kernel
and that other collections are nicely packaged in Container.

Now I can understand that others do not like what I'm doing but I will  
just continue.

I have Grid, LinkedList, DoubleLinkedList,
I have on my disc
two implementation of Trees
I should harvest BTrees and SkipList.

If people want to help they are welcome, else I will just do it alone.

Stef


Hi,

There exists a very elegant algorithm to detect cycles in linked lists.

  https://en.wikipedia.org/wiki/Cycle_detection#Tortoise_and_hare

I know that our LinkedList was written with the assumption that there  
are no cycles. However, it seems to me that it would be nice to have a  
test to check for cycles. This could be useful while printing or  
inspecting a LinkedList (and prevent things from blowing up when there  
is a cycle).


Here is the implementation:

LinkedList>>#containsCycle
  | slow fast |
  slow := fast := firstLink.
  [ slow notNil and: [ fast notNil and: [ fast nextLink notNil ] ] ]
whileTrue: [
  slow := slow nextLink.
  fast := fast nextLink nextLink.
  slow == fast
ifTrue: [ ^ true ] ].
  ^ false

And one of the tests:

LinkedListTests>>#testCycles
  1 to: 42 do: [ :each |
list := LinkedList withAll: (1 to: each).
"Warning: the following statement creates a cylce,
 inspecting/viewing list will probably fail"
list lastLink nextLink: list firstLink.
self assert: list containsCycle ]

Opinions ?

Sven





--
Using Opera's mail client: http://www.opera.com/mail/



[Pharo-dev] test please ignore

2016-11-22 Thread stepharo



--
Using Opera's mail client: http://www.opera.com/mail/



[Pharo-dev] This is a test

2016-11-22 Thread stepharo



--
Using Opera's mail client: http://www.opera.com/mail/



Re: [Pharo-dev] Improving comments cool action

2016-11-20 Thread stepharo

Now we have package comments :) so we should take also advantage of them.

Stupid question, how exactly does one add package comments ? Can it only be 
done in the latest 6 ? Is it somehow compatible with older versions ?

In latest version you press on a package and comment and you can accept 
text.


Is it somehow compatible with older versions ?

I do not know. I did not check its implementation.
I imagine that the package comments is stored in the manifest. So it is 
probably not displayed but not lost if you load your package in Pharo 50.





[Pharo-dev] Improving comments cool action

2016-11-20 Thread stepharo

Hi guys

I would like to see how we could build a concerted action to improve the 
class and method comments in Pharo.


Now we have package comments :) so we should take also advantage of them.

I would love that a newbie is highlithed by class comments.

So I would like to start to comment key core classes.

I'm sure that if we all spend 30 min per week we can really have a huge 
impact.


I was planning to start with collection classes.

Now let me know if you want to help.

Stef




Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

2016-11-14 Thread stepharo

Hi thierry


did you happen to have a techreport or any description of your work?


Stef


Le 11/11/16 à 11:44, Thierry Goubier a écrit :

Le 11/11/2016 à 11:29, Stephan Eggermont a écrit :

On 10/11/16 21:35, Igor Stasenko wrote:

No, no, no! This is simply not true.
It is you, who writes the code that generates a lot of statistical
data/analysis data, and its output is fairly predictable.. else you are
not collecting any data, but just a random noise, isn't?


That would be green field development. In brown field development, I
only get in when people start noticing there is a problem (why do we
need more than 4GBytes for this?). At that point I want to be able to
load everything they can give me in an image so I can start analyzing
and structuring it.

I mean, Doru is light years ahead of me and many others in field of 
data

analysis.. so what i can advise to him on his playground?


Well, the current FAMIX model implementation is clearly not well
structured for analyzing large code bases. And it is difficult to
partition because of unpredictable access patterns and high
interconnection.


This is why you look for a general purpose, efficient off-loading 
scheme, trying to optimize a general case and get reasonable 
performance out of it (a.k.a fuel, but designed for partial unloading 
/ loading: allow dangling references in a unit of load, focus on 
per-page units to match the underlying storage layer or network).


I wrote one such layer for VW a long time ago, but didn't had time to 
experiment / qualify some of the techniques in it. There was an 
interesting attempt (IMHO ... wasn't qualified) at combining paging 
and automatic refinement of application working set, based on previous 
experience implementing a hierarchical 2D object access scheme for 
large datasets on slow medium (decreased access time from 30 minutes 
to about a few seconds).


The other approach I would look is take some of the support code for 
such an automatic layer and use it to unload parts of my model;, and 
I'm pretty sure that, if I don't bench intensively, I'll get the 
partitioning wrong :(


Overall, an interesting subject, totally not valid from a scientific 
point of view (the database guys have already solved everything). Only 
valid as a hobby, or if a company is ready to pay for a solution.


Thierry







Re: [Pharo-dev] macOS Sierra support

2016-11-14 Thread stepharo

Good

Tx


Le 14/11/16 à 11:36, Esteban Lorenzano a écrit :
for the moment, I added this nice (?) alert when you press mac 
download button:



On 14 Nov 2016, at 11:30, Esteban Lorenzano > wrote:



On 14 Nov 2016, at 11:01, MartinW > wrote:


Can someone put a note to the website (http://pharo.org/download)? It is
frustrating for users to follow the link to
http://files.pharo.org/platform/Pharo5.0-mac.zip from there and get a
defunct Pharo installation.


no, in fact that link should work.
… and in fact, it works… is just that due the changes in sierra, the 
bundle needs to be put in /Applications to not be copied into a 
sandbox, readonly place.


I’m working on have this working in a different way: is time to make 
PharoLauncher the default download. That way it will be in 
/Applications naturally and your images will be in a correct place 
naturally (I also would like a “add command line tools” option to 
install a pharo and pharo-ui in /usr/local/bin).


Esteban




Sean P. DeNigris wrote


EstebanLM wrote

the regular download by zeroconf should give you an usable VM.

That worked - thanks!


Yes, this VM works well :)



--
View this message in context: 
http://forum.world.st/macOS-Sierra-support-tp4917181p4922891.html
Sent from the Pharo Smalltalk Developers mailing list archive at 
Nabble.com .










Re: [Pharo-dev] http://tracker.pharo.org down ?

2016-11-13 Thread stepharo

esteban do we have a how to somewhere?


Le 13/11/16 à 14:02, Esteban Lorenzano a écrit :

it was down, I restarted it (along with the catalog).

Esteban


On 13 Nov 2016, at 10:28, Nicolai Hess  wrote:

can not create a slice for an issue:
ZnHttpUnsuccessful: 503 Service Temporarily Unavailable








Re: [Pharo-dev] Invoice management

2016-11-11 Thread stepharo

Hi

I started to build silly bills using Artefact (and I should finish).

I saw that I should add more components to Artefact and it is on my todo.

Doing so I discover that there is a super cool library for date printing 
in Zn.


Stef


Le 11/11/16 à 18:48, Trussardi Dario Romano a écrit :

Ciao,

I hope this email and relative question does not create problems to the 
list.

A dear friend asked me if I was able to handle the invoice management:

1 ) create the document with some items

2)  print and save the document

3) have the possibility to make some queries on the documents

Someone realized something in this direction  based on Smalltalk ( 
Pharo ) ?

A base development with possibly to customize..


Thanks for any considerations.


Dario






Re: [Pharo-dev] why sparta depends on Taskit?

2016-11-06 Thread stepharo
I tried to open the image that glenn gave me and I can browse the code 
(I got an FFI problem due to the fact that the lib is not present).


I tried and I could open the image from the ci with the vm glenn sent me.

So I will update my vm.

Stef



Le 6/11/16 à 20:19, Tudor Girba a écrit :

Hi,

It does not work to run the Bloc examples with the regular VM, but it does work 
to browse the code. Stef is saying that he cannot browse code in the Bloc image.

This is a significant problem, but I just do not see why this is so. So, it 
would be very useful for us to learn where this problem could come from.

Doru



On Nov 6, 2016, at 7:01 PM, Aliaksei Syrel  wrote:

Hi

Just taking Bloc image from CI does not work. Don't forget that you need Sparta 
plugin (libMoz2D.dylib/DLL/so). I didn't find a way how to ship plugin with 
image, sorry...

It can be downloaded from bintray https://bintray.com/syrel/Moz2D/libMoz2D.

Cheers
Alex


On Nov 6, 2016 4:58 PM, "Tudor Girba"  wrote:
Hi,

I think there are a couple of thinks that are mixed up.

First, the image from CI:
- download the latest image built on October 12 on Jenkins:
https://ci.inria.fr/pharo-contribution/job/Bloc/PHARO=60,VERSION=development,VM=vm/lastSuccessfulBuild/artifact/Bloc.zip
- run it either with the stable of the latest VM
==> you should get no crash when opening the image (I just checked again)

The code loading is a bit strange. I just tried and I do now know why this does 
not work from the command line on Mac. For me it somehow hanged while loading 
PetitCSS. There is something strange with Metacello and projects that depend on 
Glamour that I could not quite fully understand yet and I am looking at it 
since a month. Dale, I need your help, but I will follow up on this :).

At the same time, I can reliably load the code using this script from a fresh 
Pharo image and the latest VM:

Gofer it
smalltalkhubUser: 'Pharo' project: 'Bloc';
configuration;
loadDevelopment.

Can you please try this one?

Cheers,
Doru




On Nov 6, 2016, at 11:24 AM, stepharo  wrote:

I got to the ci and I click on the image and download and drop it on my vm=> 
crash.
Why doing a video?

open a shell

 wget -O - http://get.pharo.org/60+vm | bash
./pharo Pharo.image config http://www.smalltalkhub.com/mc/Pharo/Bloc/main 
ConfigurationOfBloc --install=development

And it fails loading taskit.

Stef




Le 6/11/16 à 11:01, Aliaksei Syrel a écrit :

The best would be if you could make a video of how you install Bloc and send to 
Glenn. Because it works for us and for Travis CI. Sound like you face a 
strange and not so easy to catch issue.

Cheers
Alex


On Nov 5, 2016 6:54 PM, "stepharo"  wrote:
why sparta depends on Taskit?


Since I cannot load it I cannot try to understand. I find strange that a 
graphical canvas depends on a concurrent task management system.

I tried to follow the instruction given by glenn and it failed. So so far I 
could not see any recent versions of Bloc.

I do not understand why the image produced by the jenkins job crashes my vm.


Stef


wget -O - http://get.pharo.org/60+vm | bash
./pharo Pharo.image config http://www.smalltalkhub.com/mc/Pharo/Bloc/main 
ConfigurationOfBloc --install=development


just failed yesterday for me.



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

"What we can governs what we wish."






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

"Not knowing how to do something is not an argument for how it cannot be done."








Re: [Pharo-dev] why sparta depends on Taskit?

2016-11-06 Thread stepharo
may be my vm is old but this is a spur one. I will try with the latest 
one and report.



stef


Le 6/11/16 à 20:19, Tudor Girba a écrit :

Hi,

It does not work to run the Bloc examples with the regular VM, but it does work 
to browse the code. Stef is saying that he cannot browse code in the Bloc image.

This is a significant problem, but I just do not see why this is so. So, it 
would be very useful for us to learn where this problem could come from.

Doru



On Nov 6, 2016, at 7:01 PM, Aliaksei Syrel  wrote:

Hi

Just taking Bloc image from CI does not work. Don't forget that you need Sparta 
plugin (libMoz2D.dylib/DLL/so). I didn't find a way how to ship plugin with 
image, sorry...

It can be downloaded from bintray https://bintray.com/syrel/Moz2D/libMoz2D.

Cheers
Alex


On Nov 6, 2016 4:58 PM, "Tudor Girba"  wrote:
Hi,

I think there are a couple of thinks that are mixed up.

First, the image from CI:
- download the latest image built on October 12 on Jenkins:
https://ci.inria.fr/pharo-contribution/job/Bloc/PHARO=60,VERSION=development,VM=vm/lastSuccessfulBuild/artifact/Bloc.zip
- run it either with the stable of the latest VM
==> you should get no crash when opening the image (I just checked again)

The code loading is a bit strange. I just tried and I do now know why this does 
not work from the command line on Mac. For me it somehow hanged while loading 
PetitCSS. There is something strange with Metacello and projects that depend on 
Glamour that I could not quite fully understand yet and I am looking at it 
since a month. Dale, I need your help, but I will follow up on this :).

At the same time, I can reliably load the code using this script from a fresh 
Pharo image and the latest VM:

Gofer it
smalltalkhubUser: 'Pharo' project: 'Bloc';
configuration;
loadDevelopment.

Can you please try this one?

Cheers,
Doru




On Nov 6, 2016, at 11:24 AM, stepharo  wrote:

I got to the ci and I click on the image and download and drop it on my vm=> 
crash.
Why doing a video?

open a shell

 wget -O - http://get.pharo.org/60+vm | bash
./pharo Pharo.image config http://www.smalltalkhub.com/mc/Pharo/Bloc/main 
ConfigurationOfBloc --install=development

And it fails loading taskit.

Stef




Le 6/11/16 à 11:01, Aliaksei Syrel a écrit :

The best would be if you could make a video of how you install Bloc and send to 
Glenn. Because it works for us and for Travis CI. Sound like you face a 
strange and not so easy to catch issue.

Cheers
Alex


On Nov 5, 2016 6:54 PM, "stepharo"  wrote:
why sparta depends on Taskit?


Since I cannot load it I cannot try to understand. I find strange that a 
graphical canvas depends on a concurrent task management system.

I tried to follow the instruction given by glenn and it failed. So so far I 
could not see any recent versions of Bloc.

I do not understand why the image produced by the jenkins job crashes my vm.


Stef


wget -O - http://get.pharo.org/60+vm | bash
./pharo Pharo.image config http://www.smalltalkhub.com/mc/Pharo/Bloc/main 
ConfigurationOfBloc --install=development


just failed yesterday for me.



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

"What we can governs what we wish."






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

"Not knowing how to do something is not an argument for how it cannot be done."








Re: [Pharo-dev] http://pharo.org/files/pharo.png

2016-11-06 Thread stepharo

No idea but it should not because it breaks our nice examples.

if you have the file I can add it back.

May be esteban when he was removing Amber dependencies in Marina.

Stef


Le 6/11/16 à 18:14, Sven Van Caekenberghe a écrit :

Who removed http://pharo.org/files/pharo.png ?

Why ?

It is used in tests/examples.

Could it be put back please, even it is not used (it does do no harm) ?

A basic rule of the Web is not to break existing stuff.

yes but there is no become/allInstances to find who is using you


Sven







Re: [Pharo-dev] why sparta depends on Taskit?

2016-11-06 Thread stepharo

Hi doru




Hi,

I think there are a couple of thinks that are mixed up.


yes they both contribute to making bloc not accessible to mortals.


First, the image from CI:
- download the latest image built on October 12 on Jenkins:
https://ci.inria.fr/pharo-contribution/job/Bloc/PHARO=60,VERSION=development,VM=vm/lastSuccessfulBuild/artifact/Bloc.zip
- run it either with the stable of the latest VM
==> you should get no crash when opening the image (I just checked again)

It crashes with me systematically. May be this is not the latest stable vm.

The code loading is a bit strange. I just tried and I do now know why this does 
not work from the command line on Mac. For me it somehow hanged while loading 
PetitCSS. There is something strange with Metacello and projects that depend on 
Glamour that I could not quite fully understand yet and I am looking at it 
since a month. Dale, I need your help, but I will follow up on this :).
At least I'm not the only one. guille told me that the problem is not in 
taskit because his jobs are fully working.

At the same time, I can reliably load the code using this script from a fresh 
Pharo image and the latest VM:

Good to know


Gofer it
smalltalkhubUser: 'Pharo' project: 'Bloc';
configuration;
loadDevelopment.

Can you please try this one?


I will.
Now I'm busy and since I cannot push little fixes
I'm not really interested to lose time.

I checked the code with the image glenn sent me and since there is not 
enough good class comments I
decided that I will not invest. I'm kind of fed up losing my time 
reverse engineering other code.


STef

Cheers,
Doru




On Nov 6, 2016, at 11:24 AM, stepharo  wrote:

I got to the ci and I click on the image and download and drop it on my vm=> 
crash.
Why doing a video?

open a shell

 wget -O - http://get.pharo.org/60+vm | bash
./pharo Pharo.image config http://www.smalltalkhub.com/mc/Pharo/Bloc/main 
ConfigurationOfBloc --install=development

And it fails loading taskit.

Stef




Le 6/11/16 à 11:01, Aliaksei Syrel a écrit :

The best would be if you could make a video of how you install Bloc and send to 
Glenn. Because it works for us and for Travis CI. Sound like you face a 
strange and not so easy to catch issue.

Cheers
Alex


On Nov 5, 2016 6:54 PM, "stepharo"  wrote:
why sparta depends on Taskit?


Since I cannot load it I cannot try to understand. I find strange that a 
graphical canvas depends on a concurrent task management system.

I tried to follow the instruction given by glenn and it failed. So so far I 
could not see any recent versions of Bloc.

I do not understand why the image produced by the jenkins job crashes my vm.


Stef


wget -O - http://get.pharo.org/60+vm | bash
./pharo Pharo.image config http://www.smalltalkhub.com/mc/Pharo/Bloc/main 
ConfigurationOfBloc --install=development


just failed yesterday for me.



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

"What we can governs what we wish."











[Pharo-dev] About balkanisation

2016-11-06 Thread stepharo

Hi

I would like that you think a bit about our community and that there is 
a value in using common tools


to share and develop common libraries. Because to me it feels like we 
are getting balkanize.



It may look super cool and be hyper trendy to use github (because like 
that you can say that you use latest hyper cool


features), but I would like to ask especially people building libraries 
to pay attention that it is important


that other people can contribute back easily and that there is an easy 
way to load/contribute.


Today I experienced Bloc

- I cannot load code and I cannot contribute.

- I saw mdl with a mixture between smalltalkhub and github (sounds 
super hyper cool) and I saw paul not being able to contribute :(



Yes you can say that monticello sucks yes it is terrible yes we all fell 
like Cobol programmers but at the end of the day.


Yes the herb is always greener elsewhere. Yes yes yes. Let us take some 
facts.


We managed pharo and moose with it over the last 8 years successfully 
and Pharo and moose are not 5 packages together from


what I can see. So pay attention about the decision you take.

Now we will provide git support (this is 8 months that nicolas is 
exclusively working/thinking/dreaming


about that) and that we are doing experiments (Guille is managing the 
bootstrap in github).


Now when everybody will have its own little project lost on github (I do 
not count the amount of time I do not find pillar on github because I forget


that it is called pillar-markup), what will we do.

So we need an infrastructure to handle this and christophe is working on 
this.


I think that you should consider the accidental complexity as something 
that we can minimise by using patterns and common practices.


Now you can think that I'm an idiot and that I have no vision (be my 
guest) but we should pay attention because we are a small community.


Stef






Re: [Pharo-dev] [Bloc] Hierarchy of BiEvent

2016-11-06 Thread stepharo



Le 27/10/16 à 10:57, Guille Polito a écrit :

Something itches me from this discussion.

I somehow find myself with Glenn:
- should Bloc work with other than SDL/OSWindow?
- should SDL/OSWindow work with other than Bloc?

Merging the event hierarchy may prevent these two scenarios. And these 
scenarios are not only really possible: this is what the current 
scenario is. On one hand SDL and OSWindow work today with Morphic 
besides Block. On the other hand Bloc is, after all, an external 
library loaded on top of Pharo.


To explain better what I think:

- First I have the feeling that BIEvent and OSEvent are not the same 
thing. They have the same *NAME*. But they model different concepts. 
What is an event in bloc does not make sense in OSWindow and 
vice-versa. Why? because OSWindow does not manage widgets nor 
interactions between them.


- Second, I think that this idea of merging these hierarchies means 
merging layers also, what leads also to our monolithic system. I agree 
that this may impose some maintenance burden because there is the 
maintenance of the two layers plus their mapping (e.g., between the 
low-level events and the high-level events). But otherwise we are 
tampering the modularity.


Now, I liked more the suggestion of making Bloc using SDLEvents directly.

But then, wasn't it an idea behind OSWindow that users of OSWindow 
should be somehow abstracted from the backend behind. And SDL be just 
a backend? Something like Athens and Cairo.


Is SDL meant to work alone or be just a backend for OSWindow? Because 
if the case is the later, then maybe it makes sense to do the inverse: 
SDL should generate directly OSEvents and we should not have SDLEvent.


may be.
Now I do not think that doing more than two transformations is good.



And going even further: Is OSWindow used in isolation? e.g., without 
morphic or bloc.


Because then, it the problem is the runtime overhead OSWindow should 
maybe not reify its events but propose a low level event handler 
mechanism where we could have


MorphicOSWindowEventHandler
  >> keyEvent: ...
  >> mouseEvent: ...

BlocOSWindowEventHandler
  >> keyEvent: ...
  >> mouseEvent: ...

And each framework generates its own events from low level SDL data. 
No event transformations, less duplications, and both Bloc and Morphic 
are plugged on top of OSWindow but not really strongly coupled to it.

may be






Re: [Pharo-dev] why sparta depends on Taskit?

2016-11-06 Thread stepharo

Hi


Hi

Sparta definitely does not depend on TaskIt :) I have no idea what is it.



Ok we are safe then :) I was a bit feeling dizzy about this.
I read the code and this is bloc when it launches a new task.

Now I will stop to try to look at bloc because I get just losing my time.
Sorry to have asked.

I think that I should focus on the web sadly.


Cheers
Alex


On Nov 5, 2016 6:54 PM, "stepharo" <mailto:steph...@free.fr>> wrote:


why sparta depends on Taskit?


Since I cannot load it I cannot try to understand. I find strange
that a graphical canvas depends on a concurrent task management
system.

I tried to follow the instruction given by glenn and it failed. So
so far I could not see any recent versions of Bloc.

I do not understand why the image produced by the jenkins job
crashes my vm.


Stef


wget -O - http://get.pharo.org/60+vm | bash
./pharo Pharo.image config
http://www.smalltalkhub.com/mc/Pharo/Bloc/main
<http://www.smalltalkhub.com/mc/Pharo/Bloc/main>
ConfigurationOfBloc --install=development


just failed yesterday for me.






Re: [Pharo-dev] why sparta depends on Taskit?

2016-11-06 Thread stepharo
I got to the ci and I click on the image and download and drop it on my 
vm=> crash.


Why doing a video?

open a shell

wget -O - http://get.pharo.org/60+vm | bash
./pharo Pharo.image config 
http://www.smalltalkhub.com/mc/Pharo/Bloc/main 
<http://www.smalltalkhub.com/mc/Pharo/Bloc/main> ConfigurationOfBloc 
--install=development



And it fails loading taskit.

Stef




Le 6/11/16 à 11:01, Aliaksei Syrel a écrit :


The best would be if you could make a video of how you install Bloc 
and send to Glenn. Because it works for us and for Travis CI. Sound 
like you face a strange and not so easy to catch issue.


Cheers
Alex


On Nov 5, 2016 6:54 PM, "stepharo" <mailto:steph...@free.fr>> wrote:


why sparta depends on Taskit?


Since I cannot load it I cannot try to understand. I find strange
that a graphical canvas depends on a concurrent task management
system.

I tried to follow the instruction given by glenn and it failed. So
so far I could not see any recent versions of Bloc.

I do not understand why the image produced by the jenkins job
crashes my vm.


Stef


wget -O - http://get.pharo.org/60+vm | bash
./pharo Pharo.image config
http://www.smalltalkhub.com/mc/Pharo/Bloc/main
<http://www.smalltalkhub.com/mc/Pharo/Bloc/main>
ConfigurationOfBloc --install=development


just failed yesterday for me.






[Pharo-dev] why sparta depends on Taskit?

2016-11-05 Thread stepharo

why sparta depends on Taskit?


Since I cannot load it I cannot try to understand. I find strange that a 
graphical canvas depends on a concurrent task management system.


I tried to follow the instruction given by glenn and it failed. So so 
far I could not see any recent versions of Bloc.


I do not understand why the image produced by the jenkins job crashes my 
vm.



Stef


wget -O - http://get.pharo.org/60+vm | bash
./pharo Pharo.image config 
http://www.smalltalkhub.com/mc/Pharo/Bloc/main ConfigurationOfBloc 
--install=development



just failed yesterday for me.




Re: [Pharo-dev] Newbie(ish) Question on SVG with Athens / Roassal / Spec

2016-11-05 Thread stepharo

Hi Graham




Hi

I am contemplating moving an old Pharo app (1.4 vintage) which used 
Morphic heavily into the new Pharo world (Pharo 5).
One of the options is to move a proprietary vector graphic 
implementation which draws symbols to SVG.


Looking for examples / documentation on the use of SVG (external 
files, not image defined paths) has been very frustrating.
All examples I have found have been old and none of the file based / 
load ones work.


Can anyone please point me to good documentation / examples?
I want to understand how one can use:
SVG with Athens

I think that there is an example around for SVG in Athens.
There some limits due to cairo because certain arcs are not supported by 
cairo.

SVG with Spec
Spec should be extended to offer a container displaying Athens canvas I 
imagine.



SVG loaded from a file with Roassal

I imagine that roassal does not do anything special besides using Athens.




Thanks in advance.

Graham





Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-11-05 Thread stepharo

Hi jan


will you contact to add Pharo to the list of languages because this is 
good for us to be in this list.



Stef


Le 5/11/16 à 13:55, Jan van de Sandt a écrit :

Hi Sven,

LMDB is a lean, mean and very fast storage engine. One limitation is 
that you need a 64bit proces before you can store more than 2GB of 
data. That was a downside for me until very recently :-)


LMDB is a low level key-value storage engine that runs on a single 
host. But if that is what you are looking for it seems pretty good. I 
haven't used it in any production systems yet. But it is used as a 
storage engine in quite a few open source projects. For example OpenLDAP.


Jan.

On Sat, Nov 5, 2016 at 1:43 PM, Jan van de Sandt > wrote:


Hi,

The only thing I had to do was to regenerate the accessors of the
structure classes MDBValue and MDBStat. The offsets for the fields
are different on 32 versus 64 bit systems. Perhaps we can think of
a way to generate the field accessors of structure classes such
that they work in both environments.

For now just you can just use #rebuildFieldAccessors

Jan.

On Sat, Nov 5, 2016 at 12:27 PM, Thierry Goubier
mailto:thierry.goub...@gmail.com>> wrote:

Le 05/11/2016 à 12:12, Jan van de Sandt a écrit :

Hi,

With the latest 64bits VM (201611042126) and image (60282)
UFFI is also
looking good. I'm testing a small library of mine [1] to
interface with
LMDB [1], a memory mapped key-value database. Almost all
tests are
green. This is great progress!


Hi Jan,

did you have to change your UFFI definitions to match the
64bits version of your lib?

Thierry

I only ran into one issue, a PrimitiveFailed error with
#basicIdentityHash in the SmallFloat64 class.

Cheers,
Jan.

[1] http://smalltalkhub.com/#!/~JanVanDeSandt/LightningMDB

[2]
https://symas.com/products/lightning-memory-mapped-database/



On Fri, Oct 28, 2016 at 11:56 AM, Esteban Lorenzano
mailto:esteba...@gmail.com>
>>
wrote:

VM here:
http://bintray.com/estebanlm/pharo-vm/build#files/

>
Image here:
http://files.pharo.org/get-files/60/pharo-64.zip

>

this is still not official (that’s why is not in
official place) so
there are a couple of known problems:

- version format is different, and that breaks some
things in image
that depends on it to know what happens
- command line is different and probably you’ll need
to play a bit
with options (one or two dashes).
- UFFI has some failing tests (but most of it works).

I would appreciate some help to report and/or fix the
emerging
problems.

cheers,
Esteban

On 28 Oct 2016, at 10:39, Thierry Goubier
mailto:thierry.goub...@gmail.com>
>> wrote:

Hi all,

anybody knows how to get (and test) the 64bits
version of the
Pharo vm and image?

Thanks,

Thierry











Re: [Pharo-dev] pillar highlight text in code

2016-11-05 Thread stepharo

Yes I should fix them.



Le 3/11/16 à 23:52, Nicolai Hess a écrit :



2016-11-03 23:50 GMT+01:00 Nicolai Hess >:


Can we highlight a piece of code?
In the updated PBE (Reflection chapter) there is the text:
"Change the definition of Integer>>>factorial by inserting the
underlined expression as shown below"
But I can not see the "underline" in the code example. Is it even
possible to add such text properties to a "code-style" formatted
text ?

BTW, the method name is wrong (in both places)
Integer>>#factorial
not
Integer>>>factorial



actually all code examples in that chapter uses
>>>
instead of
>>#





Re: [Pharo-dev] Keyboard list item navigation in Sender browser is strange

2016-11-05 Thread stepharo
Denis showed me that this is the normal behavior since the list 
indicates where the mouse is.



Le 3/11/16 à 21:54, stepharo a écrit :

Hi guys

If I click on an item in the message browser. The previous item gets 
deselected and the new one selected.


Now if I use arrows, the previous items is greyed out.

Are you seeing the same?


Stef









Re: [Pharo-dev] roundTo: strange behavior

2016-11-04 Thread stepharo



Le 4/11/16 à 17:03, werner kassens a écrit :

Hi Stephan,
definitely no. after the test is run, the seed has changed, perhaps 
you did not reset the seed. 

I just run the test. Nothing else.


ill look into this  this night, have to work now, ok?

tx!


werner

On 11/04/2016 03:29 PM, stepharo wrote:

Hi guys

I loaded the slice 15471 of werner and I run

https://pharo.fogbugz.com/f/cases/15471/Can-t-round-Float-fmax-to-2-decimal-places 




testIfCompletelyBroken

"If the results are not these values (accounting for precision of 
printing)

then something is horribly wrong"

gen seed: 2345678901.
self assert: (((1 to: 10) collect: [:i | gen next round: 15]) = 
#(0.149243269650845 0.331633021743797 0.75619644800024 
0.393701540023881 0.941783181364547 0.549929193942775 
0.659962596213428 0.991354559078512 0.696074432551896 
0.922987899707159 )).


I get the following. Is it correct?

#(0.220388752510952 0.073763451573329 0.74233059293699 
0.350275491993071 0.080193927548916 0.819340314631974 
0.652668019594936 0.391405332084468 0.349416343657959 0.640487859323848)












Re: [Pharo-dev] roundTo: strange behavior

2016-11-04 Thread stepharo

Hi guys

I loaded the slice 15471 of werner and I run

https://pharo.fogbugz.com/f/cases/15471/Can-t-round-Float-fmax-to-2-decimal-places


testIfCompletelyBroken

"If the results are not these values (accounting for precision of 
printing)

then something is horribly wrong"

gen seed: 2345678901.
self assert: (((1 to: 10) collect: [:i | gen next round: 15]) = 
#(0.149243269650845 0.331633021743797 0.75619644800024 0.393701540023881 
0.941783181364547 0.549929193942775 0.659962596213428 0.991354559078512 
0.696074432551896 0.922987899707159 )).


I get the following. Is it correct?

#(0.220388752510952 0.073763451573329 0.74233059293699 0.350275491993071 
0.080193927548916 0.819340314631974 0.652668019594936 0.391405332084468 
0.349416343657959 0.640487859323848)




Re: [Pharo-dev] About setProperty:toValue: vs. valueOfProperty:

2016-11-04 Thread stepharo

Thanks henrik this is cool and now I can do diffs and other.

I started to get the list of sender of setProperty:toValue: and one by 
one analyse them.



Le 3/11/16 à 21:25, Henrik Nergaard a écrit :

| dct arr |

dct := IdentityDictionary new.

arr := #(
#valueOfProperty:
#valueOfProperty:ifAbsent:
#valueOfProperty:ifAbsentPut:
#setProperty:toValue:
#hasProperty:
).

Morph withAllSubclasses do: [ :class |
class methods do: [ :each |
each ast allChildren
select: [ :c |  c isMessage and: [ arr includes: c 
selector ] ]
thenDo: [ :c |
dct
at: c selector
ifPresent: [ :col | col add: c ]
ifAbsentPut: [ OrderedCollection with: 
c ]
]
]
].

dct

--

Best regards,
Henrik

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of stepharo
Sent: Thursday, November 3, 2016 8:48 PM
To: Pharo Development List 
Subject: [Pharo-dev] About setProperty:toValue: vs. valueOfProperty:

I would like to be able to compare the **arguments** passed to

setProperty:toValue:

and

the ones of valueOfProperty:, valueOfProperty:ifAbsent:, 
valueOfProperty:ifAbsentPut:,

and

hasProperty:

I quite sure that we will discover more deadcode in morphic.

Any ideas?



PS: I hope (but I cannot read the code of Bloc because it crashes my vm at 
startup) that Bloc and Brick will not use such patterns.

There are plague and lead to shitty and crappy code.


Stef







[Pharo-dev] the kind of code I would like to avoid....

2016-11-03 Thread stepharo
I do not get why a property is useful here and why not just a temp is 
not good enough.


Especially since there are no other users of the property.


displayFiltered: evt
| matchStr matches feedbackMorph |

matchStr := self valueOfProperty: #matchString.
matches := self menuItems select: [:m | | isMatch |
isMatch := matchStr isEmpty or: [
m contents includesSubstring: matchStr caseSensitive: false
].
m isEnabled: isMatch.
isMatch
].
feedbackMorph := self valueOfProperty: #feedbackMorph.
feedbackMorph ifNil: [
feedbackMorph :=
TextMorph new
autoFit: true;
color: Color darkGray.
self
addLine;
addMorphBack: feedbackMorph lock.
self setProperty: #feedbackMorph toValue: feedbackMorph.
self fullBounds.  "Lay out for submorph adjacency"].
feedbackMorph contents: '<', matchStr, '>'.
matchStr isEmpty ifTrue: [
feedbackMorph delete.
self lastSubmorph delete.
self removeProperty: #feedbackMorph
].
" This method is invoked with evt = nil from MenuMorph >> 
removeMatchString. The current implementation can't select an item 
without an event. (Yet :D)"

   (evt notNil and: [ matches size >= 1 ])
ifTrue: [self selectItem: matches first event: evt]




Re: [Pharo-dev] why RBComment is not called RBCommentNode

2016-11-03 Thread stepharo

But how does this fit with a tree structure. For example, should “comment5” be 
associated with the “b” variable node, or the #foo:bar: message, or the 
sequence node that contains the #foo:bar: message, or the block or method node 
that contains the sequence node. You can choose, but only the writer of the 
comment can tell if you are right.

How tokens solves this problem?
I think that we do not really care one objective is to be able to 
recreate the code from the tree. I worked on a project in C
where the guys want to know if the code is well commented and we built 
heuristics to associate the comments to the closest node.



We do not have a structure that is responsible for that order.
We could have two entries in AST node;
one discrete where you can cherrypick what you want receiver arguments 
selector
and one that represent the node placement.

Now when we emit bytecode comment would do nothing.

How having them as token helps? You will visit the receiver and check if it has 
a token and place it.
I found that strange that comments are not part of the code tree as first class 
citizen.

Tokens are essentially what they are now — although they aren’t in the RBToken 
hierarchy. So far, the only advantages that I’ve heard you mention for nodes 
are visiting nodes and having a parent. The example above shows why neither of 
these are valid — you can’t determine what is the correct parent for the 
comment.

Anyway, I think comments should not be in code, but rather on code. When you 
add a comment, you would select a node or nodes that it applied to. When 
viewing a method, the comment could be displayed inline (like we have now), off 
to the side like reviewer comments in word processors, or a highlight that when 
you move the mouse over would show in a popup.

Yes you are right.


Furthermore, there could be different comment types. For example, one could 
have design comments, todo/review comments, example code comments, bug fix 
comments, etc. The code view could be customized to show each one differently. 
Comments could have pictures and other non-string items.

It would be really nice to have that.
I would put optional type declaration (and they should be optional).
Now for the main comment of a method I would not separate it because 
this is too important.

Having comments as objects outside the method’s source string would allow them 
to be easily searched. For example, someone could search for a certain bug fix. 
Currently, if a bug fix id is in a comment, it requires a full text search of 
all method text. This is slow. Therefore, many companies start adding these bug 
fix ids to the code as symbols so that a senders search will work. I’ve seen 
companies that put symbols like #Fix12345 as statements inside of methods. 
However, this doesn’t work for Smalltalk’s that remove unused literals, so in 
those cases they do something like adding a statement like #Fix12345 == 
#Fix12345 which generally isn’t optimized away.

:)

In addition to comments, I believe that annotations (not primitives) should be 
on code instead of in code like they are now. With a good implementation one 
could unify the concepts of comments and annotations.

Yes this is interesting.
Now the problem with annotations is that you have two kinds;
- the ones that decorate
- the ones that change or define the semantics (for those ones I 
would not separate) them

Furthermore, if comments are nodes, how do they affect all of the code 
rewriting and validation that is part of the RB and its rewrite tools

With comments cannot act as nullobjects for such operation?

Yes, someone could spend time making all of this work with the existing code. 
However, why not fix the real problem in that comments and methods should not 
be a single string, but rather objects.


Marcus did that during his phd and he blew up memory. So after we 
got a guy that worked on tree compression but he never finished.

Because this is the part that makes all these ideas flying or not.

Anyway thanks for the discussion. It lets me think and I learn 
something. I improved the class comment.
Because if it would have been good in the first place I would not even 
ask the question.



John Brant






[Pharo-dev] Keyboard list item navigation in Sender browser is strange

2016-11-03 Thread stepharo

Hi guys

If I click on an item in the message browser. The previous item gets 
deselected and the new one selected.


Now if I use arrows, the previous items is greyed out.

Are you seeing the same?


Stef





[Pharo-dev] shoreline, GT, renaku dev please listen

2016-11-03 Thread stepharo

Hi guys

Please read the following

https://pharo.fogbugz.com/f/cases/19288/Sending-translated-should-not-be-the-responsibility-of-the-client-of-a-Setting-description-case


There is no need to do description: 'blo' translated in setting def. 
because it is already done internally (how it should be).


I hope that yuriy will harvest this nice rule.

I browsed the 1099 users of description:/translated and fixed the ones 
that needed to be fixed.


Can you pay attention to merge back in your stream?

Stef




[Pharo-dev] About setProperty:toValue: vs. valueOfProperty:

2016-11-03 Thread stepharo

I would like to be able to compare the **arguments** passed to

setProperty:toValue:

and

the ones of valueOfProperty:, valueOfProperty:ifAbsent:, 
valueOfProperty:ifAbsentPut:,


and

hasProperty:

I quite sure that we will discover more deadcode in morphic.

Any ideas?



PS: I hope (but I cannot read the code of Bloc because it crashes my vm 
at startup) that Bloc and Brick will not use such patterns.


There are plague and lead to shitty and crappy code.


Stef




[Pharo-dev] TheManifestBuilder>>#packageNameOf:

2016-11-03 Thread stepharo

Still a name around

https://pharo.fogbugz.com/f/cases/19282/Still-name-used

The method Object>>#name called from TheManifestBuilder>>#packageNameOf: 
has been deprecated.
Implement your own domain representation of an object, or use #asString 
or #printString instead.


Select Proceed to continue, or close this window to cancel the operation.


Stef




Re: [Pharo-dev] why RBComment is not called RBCommentNode

2016-11-03 Thread stepharo

https://pharo.fogbugz.com/f/cases/19281/We-should-improve-the-class-comment-of-RBComment

If we would have better comments a kind of a dream.

Stef



Re: [Pharo-dev] some little static analysis with great impact

2016-11-03 Thread stepharo



Le 3/11/16 à 15:52, Esteban Lorenzano a écrit :

wouldn’t this be better to solve this with QA?

but QA needs the analysis first.



On 3 Nov 2016, at 15:17, stepharo  wrote:

Hi

I often end up forgetting a period.

printOn: aStream
super printOn: aStream.
aStream nextPutAll: ' "'
aStream nextPutAll: contents.
aStream nextPutAll: '" '.


And statically the system could see it with a simple heuristics:

if the message as the same name as self, super, a tmp or an argument

May be there is a missing period.

Could the compiler get this analysis?

Stef










Re: [Pharo-dev] why RBComment is not called RBCommentNode

2016-11-03 Thread stepharo



A comment isn’t code. The nodes are for code. A comment is more like a token — 
RBComment basically has the same two instance variables as RBToken. Should 
tokens also be nodes? For example, should a left paren token be represented as 
a node?

If a comment is a node, how is it visited?
For example, if you have (“comment1” self “comment2” foo: “comment3” a bar: 
“comment4” b “comment5”), what is the traversal order for the nodes?
To reproduce the code as it was typed why the representation a message 
is not a sequence. because you need to encode that you

have comment1 and self and comment2
We do not have a structure that is responsible for that order.
We could have two entries in AST node;
one discrete where you can cherrypick what you want receiver 
arguments selector

and one that represent the node placement.

Now when we emit bytecode comment would do nothing.

How having them as token helps? You will visit the receiver and check if 
it has a token and place it.
I found that strange that comments are not part of the code tree as 
first class citizen.



Furthermore, if comments are nodes, how do they affect all of the code 
rewriting and validation that is part of the RB and its rewrite tools

With comments cannot act as nullobjects for such operation?

Stef



[Pharo-dev] some little static analysis with great impact

2016-11-03 Thread stepharo

Hi

I often end up forgetting a period.

printOn: aStream
super printOn: aStream.
aStream nextPutAll: ' "'
aStream nextPutAll: contents.
aStream nextPutAll: '" '.


And statically the system could see it with a simple heuristics:

if the message as the same name as self, super, a tmp or an argument

May be there is a missing period.

Could the compiler get this analysis?

Stef




[Pharo-dev] AST-Nodes API

2016-11-03 Thread stepharo

Hi


I would love to get a more regular API for the AST Nodes.

Point 1

For example

I would love to have


leftBar -> leftBarToken to make sure that we see 
immediately the fact that we do not get a node.



for example

RBValueNode subclass: #RBArrayNode
instanceVariableNames: 'left right statements periods'
classVariableNames: ''
package: 'AST-Core-Nodes'

is not really good since I have to remember "oh yes left = {


Point 2

Apparently it is implied that we always get nodes so

now when I get a methodNode


messageNode receiver

-> node


to get the text

messageNode receiver

I have no idea.

While working on pharodoc (it is just great) I faced the problem that I 
really like to know what I'm manipulating and there is a

difference between an expression (text) and an expression node.
So what is the convention?

I would prefer to have xxxNode each time I want to get a node.



Re: [Pharo-dev] why RBComment is not called RBCommentNode

2016-11-03 Thread stepharo

Because like that

we have a correct and nice hierarchy and

all the nodes inherits from it and

we can have a nice visitor and make assumption about the root.

Regularity is nice and it helps controlling complexity.

Why a comment could not have a parent?

Stef


Le 3/11/16 à 14:53, John Brant a écrit :

Why convert it to a node? It has no affect on the running code.


John Brant


On Nov 3, 2016, at 8:23 AM, Nicolai Hess  wrote:



2016-11-03 13:41 GMT+01:00 stepharo :
Hi marcus et al

why RBComment is not called RBCommentNode and why it is not a subclass of 
RBNode?

Stef



RBComment wasn't part of the original RefactoringBrowser, it only had a 
"comments" instance variable on its nodes.
This was refactored out to its own RBComment class (I think). But no "real" 
AST-Node class.

+1 for converting this into a real AST node.









Re: [Pharo-dev] roundTo: strange behavior

2016-11-03 Thread stepharo
Ok at least we should change the comment to point to 
printShowingDecimalPlaces:


1.19 printShowingDecimalPlaces: 1

STf


Le 2/11/16 à 17:31, Nicolas Cellier a écrit :

Last thing, I'm not sure it's a good idea to deprecate round:
round: has been added to overcome the rounding problems of roundTo:
If we deprecate round:, then users will fallback to roundTo: and won't 
get correctly rounded Floats...


Thus my original question: why is there a round in python, ruby etc...
There must be other applications than just printing (we said financial 
is one).


2016-11-02 14:40 GMT+01:00 werner kassens >:


yes Martin, i get that point and i already reacted to it, i
occasionally want to calculate something with a rounded float, not
print it: apart from my harley i normally use _metric screws which
come in decimal steps.  let's end that discussion,
we are going around in circles.
werner


On 11/02/2016 02:48 AM, Martin McClure wrote:

Hi Werner,
Thanks for your comments. I posted the analysis because I did the
analysis (and thought some others might want to see it), and I
did the
analysis because I wanted to find out whether that answer was
right.
Some Smalltalks are pretty bad in similar areas of Float handling.


But aside from all the fine points, if you want a
floating-point number
to "look" nice and human-readable,
(x asFraction roundTo:(1/10))asFloat
will work, but I still recommend not rounding the number
itself, but
rounding the printing of the number. This is not a Pharo
thing, it's an
any-language-with-floats thing. In C you have printf, etc. In
Pharo, you
can use for instance:

   1.19 printShowingDecimalPlaces: 1 ==> '1.2'

This makes it easier for someone reading the code to see the
intent.

Regards,

-Martin









[Pharo-dev] why RBComment is not called RBCommentNode

2016-11-03 Thread stepharo

Hi marcus et al

why RBComment is not called RBCommentNode and why it is not a subclass 
of RBNode?


Stef




Re: [Pharo-dev] Help needed with case 19236

2016-11-03 Thread stepharo

Super cool.


Stef


Le 3/11/16 à 13:26, Denis Kudriashov a écrit :


2016-11-02 20:03 GMT+01:00 stepharo <mailto:steph...@free.fr>>:



But it leads to incompatibility for old images.

If people use Spec and we update spec = no problem :)


Yes Spec is updated by this.
And now it is fix to include




Re: [Pharo-dev] Help needed with case 19236

2016-11-02 Thread stepharo



Hi all.

We need help how to better manage issue 19236 
.


Generally: we have class Tab which is morph related to tabs widget. It 
conflicts with key mapping class variable and some similar stuff from 
Xtreams.


So this issue made rename of morph classes from tabs widget to add 
them ~Morph suffix.

I think it is good change.


+1

But it leads to incompatibility for old images.

If people use Spec and we update spec = no problem :)


So any tools which use tabs will be not working in Pharo6.

How to better manage this problem? Could we integrate this change?


Class renaming without keeping the old name is difficult.
What we did with gustavos was more for deprecating.

stef


Re: [Pharo-dev] Image Distributions [was:Re: Mocks are missing in Pharo (from thread OSProcess is missing)}

2016-11-01 Thread stepharo



Le 29/10/16 à 08:39, p...@highoctane.be a écrit :

Having them in image can indeed be useful.

I am testing against REST backends, and well, this is a destructive 
test to say the least. Not easy to replay as much as I want.


I hope that with the Bootstrap we'll be able to have a set of 
"Batteries Included" distributions. Kind of like we have Moose today, 
which I like very much as I do not have to load parts from all over 
the place.

Yes we will now people will be able to also define their own image.
At the end
bootstrap
+configura
+jenkins
= an image



On http://tcl.tk there are also a number of such distributions:

* the "Batteries Included" ActiveTcl 
(http://www.activestate.com/activetcl) with its various support levels 
[which would be good to emulate for the Pharo Pro business proposition]


* TclKit / StarKits concept (http://wiki.tcl.tk/52). TclKit is a 
BaseKit. See http://wiki.tcl.tk/15985 for a table of kits and their 
supported features.


* Build your own from sources.

TclKit allows one to build special kit, using a command line tool, 
similar to what we discuss for loading packages easily. 
http://wiki.tcl.tk/10558


We do have an image and the TclKit has a VFS (Virtual File System) 
bundling everything in a single file.


So, basically, one runs things with tclkit hello.kit. Quite 
reminiscent of pharo Pharo.image I'd say.


Question 1:

Which top 5 packages/configurations would you find useful to have 
available in a distribution?


1-
2-
3-
4-
5-

Question 2:

What do you consider to be the top 3 use cases of a Pharo Distribution 
for your own use?


1-
2-
3-

Best,
Phil



`







On Fri, Oct 28, 2016 at 8:36 PM, Denis Kudriashov 
mailto:dionisi...@gmail.com>> wrote:



2016-10-28 18:58 GMT+02:00 Guillermo Polito
mailto:guillermopol...@gmail.com>>:

No, please, kernel test should have the fewer dependencies as
possible!

I would say this dependency is needed.

And again i'll hold my position: whoever wants to load it can
do it. There is no need to put it there by default.

Do you know how much easier it would be to design and test
FileSystem with mocks. Code and tests will be much better and
simpler from the beginning.
And I could said it about any package which provide abstractions.

Now no project which is part of Pharo can use mocks for tests. So
it is not question of loading it for own project. Pharo
contributors can't use mocks.

And there is another story. Imaging Ruby guys join Pharo
development (not real story :)). Many years In Ruby people use
mocks and "human should" assertions. Most TDD evolution was from
Ruby. I imaging their impression about Pharo "the best for TDD".

And generally I would said we have quite bad tests in system. They
are slow, they corrupt image. Mocks will help to improve this
situation.






Re: [Pharo-dev] roundTo: strange behavior

2016-10-30 Thread stepharo

I'm favor to deprecate round:  too.

Thanks you all for your analysis. I will reread the thread carefully to 
learn.



Stef


Le 27/10/16 à 18:12, Martin McClure a écrit :

On 10/27/2016 04:12 AM, test wrote:
i would prefer if #round: will not be deprecated in Floats. in some 
cases Float>>#round: can be useful, eg optimization problems where 
one searched value describes the size of a screw, that exists only in 
certain sizes.


#roundTo: can be used for this (and is specified by ANSI Smalltalk, 
for those who care). If the screws only come in 16th inch increments, 
for instance, then "roundTo: 0.0625" will give you an exact result, 
since 16ths *are* exactly representable as floats.


OTOH, #round: (not in ANSI) appears to promise something that cannot 
be delivered for Floats, so is misleading, and it spreads the kind of 
confusion that resulted in this thread.


That's why I favor deprecating #round: for Floats.

Regards,

-Martin





Re: [Pharo-dev] roundTo: strange behavior

2016-10-30 Thread stepharo



Le 29/10/16 à 17:01, test a écrit :

On 10/27/2016 11:13 AM, Nicolas Cellier wrote:


feel free to improve the slice.


Hi,
i never made a slice and thought , i could eventually try 
to do that in this case, but of course i did not succeed:
1. Nicolas, i do not understand, why you put asScaledDecimal: 
numberOfWishedDecimal at the end of Fraction>>round:. what would not 
work, if one simply omitted that?
2. when i make a slice i find no possibility to save it to my pc, to 
check whether i made things correctly and there is no changes-button 
in the monticello-browser to look at the diff that slice would make. 
of course the seasoned programmer has no problems with that, but a 
simple user like me?
3. this line: "< expr: '(1/3 round: 2)' result: (33/100) >" is not 
accepted by the browser. i have no idea how to call this example to 
debug it, perhaps (33/100) is not accepted as a result because 
Fractions are no literals? and then what?



This is an experience that we should remove
"< expr: '(1/3 round: 2)' result: (33/100) >"
-> "(1/3 round: 2)' -> (33/100)"


werner

p.s. regarding your slice, Nicolas, FractionTest>>testRounding needs 
also to be changed.






Re: [Pharo-dev] roundTo: strange behavior

2016-10-30 Thread stepharo

Hi werner

to load a slice:

- select it and press load.

to create a slice

   - + slice

   - then select the package that will compose the slice

   - save the slice in the inbox

Can you retry and let me know what did not work?


Stef


Le 29/10/16 à 17:01, test a écrit :

On 10/27/2016 11:13 AM, Nicolas Cellier wrote:


feel free to improve the slice.


Hi,
i never made a slice and thought , i could eventually try 
to do that in this case, but of course i did not succeed:
1. Nicolas, i do not understand, why you put asScaledDecimal: 
numberOfWishedDecimal at the end of Fraction>>round:. what would not 
work, if one simply omitted that?
2. when i make a slice i find no possibility to save it to my pc, to 
check whether i made things correctly and there is no changes-button 
in the monticello-browser to look at the diff that slice would make. 
of course the seasoned programmer has no problems with that, but a 
simple user like me?
3. this line: "< expr: '(1/3 round: 2)' result: (33/100) >" is not 
accepted by the browser. i have no idea how to call this example to 
debug it, perhaps (33/100) is not accepted as a result because 
Fractions are no literals? and then what?

werner

p.s. regarding your slice, Nicolas, FractionTest>>testRounding needs 
also to be changed.






Re: [Pharo-dev] Mocks are missing in Pharo (from thread OSProcess is missing)

2016-10-30 Thread stepharo

Denis

We are working since 4 years now to get

- have a small kernel + tests

- be able to load nicely configurations

We should not add something else than Sunit for tests of the small 
kernels tests.


Now people can use whatever they want to test their system but for the core

we are really picky because loading on single package may add far too 
many dependencies.


and it means

- more time to load

- more time to debug

- more time to just understand what did not work during the bootstrap.

So our goal is to shrink the minimal core and not to extend it. So we 
will add mock by hand if we need them.


I agree with Guillermo. Far too much pain.

Stef

Le 28/10/16 à 18:51, Denis Kudriashov a écrit :

We always said that smalltalk is the best for TDD.
But we not have mocks by default in Pharo while mocks is fundamental 
part of TDD.

So no kernel tests could benefit from them.
And more important TDD is design process and without mocks we can't 
apply it to kernel with full power.

What you think to integrate Mocketry in Pharo 6?
It has comments and documentation (PharoInProgress, Help), advanced 
features and it is very competitive to any modern mock libraries.


Best regards,
Denis





Re: [Pharo-dev] Instructions for Pharo 6 64bits

2016-10-28 Thread stepharo



Le 28/10/16 à 16:59, Dimitris Chloupis a écrit :
does 64 bit means that we can now take full advantage of the memory of 
our system


yes


and not have to adhere to a specific limit ?

well probably the one of your OS :)

Is that something the current build does or is it planned for future 
releases ?

This one.



On Fri, Oct 28, 2016 at 4:19 PM Esteban Lorenzano > wrote:




On 28 Oct 2016, at 14:22, Thierry Goubier
mailto:thierry.goub...@gmail.com>> wrote:

apart from the missing SSL support which makes loading complex
stuff from github a bit painfull, it seems to be usable enough.


I should work on this :)

Esteban





Re: [Pharo-dev] roundTo: strange behavior

2016-10-27 Thread stepharo

Thanks ***A LOT*** nicolas.



I've put a single slice in the inbox for the 3 issues because they all 
are related.

See slice comment:

For Float, implement guard to prevent overflow (15471), and use exact 
representation for intermediate results (asFraction) so as to avoid 
double rounding problems (15473)


For Fraction (15472), choose an exact representation for result rather 
than Float. This is because such method is particularly usefull for 
financial/monetary applications.


2016-10-26 17:28 GMT+02:00 stepharo <mailto:steph...@free.fr>>:




Le 26/10/16 à 14:52, Nicolas Cellier a écrit :

Sorry for being slow minded,
yes of course financial apps is exactly the case where round:
would be usefull and NEEDS to be exact.


so what is the solution?
I'm lost again.


Hi Nicolas,
yes, i know. suppose you calc some financial thing and one
intermediate result will be in $. you have to round this
Fraction-result  to 2 decimals. now you use this to further
calc basepoints as the final result. you have to convert this
to 3 decimals. looking at this final result with 2 decimals
can be be irritating for a moment, if you debug the calcs.
and  btw i never use scaledDecimals.
werner


On 10/26/2016 02:06 PM, Nicolas Cellier wrote:



2016-10-26 13:11 GMT+02:00 test mailto:wkass...@libello.com>>:

Hi Nicolas,
regarding rounding Fractions:
i use fractions if i want to get an exact result (eg for
comparing the result with Float calculations). if
#round: returns a Float all further calcs (with
Fractions) will get contaminated, since the rest will
become Floats too. Hence the "asScaledDecimal:
numberOfWishedDecimal" seems better to me, but i wonder
why these transformations at the end are necessary at
all? just for the looks? i'd suppose every person, who
knows how to use Fractions, also knows how to append a
#asScaledDecimal: to a result by himself, should he want
that.

taking as an example financial calcs that first use 2
decimals. occasionaly the final result will be
basepoints, often small ones like 0.003. with
scaledDecimals the result would be (ok, look like) 0
since scaledDecimals also contaminate the calc. of
course one could correct this simply with an
#asScaledDecimal:3 at the end. nevertheless a first look
at the zero result would surprise me for a tenth of a
second.
werner


Hi Werner,
I don't know the purpose of round: at all.
Most often this kind of message was used before printing
probably because lack of versatile formatted print messages.
In Squeak I replaced most usages of roundTo: by
printShowing(Max)DecimalPlaces:.
Now if it has been added in Pharo and other languages, there
must be some use cases I presume.
Maybe the analysis could be carried on these use cases?

Beware, converting a Fraction asScaledDecimal will NOT round.
Only the printString is rounded, but the number keeps its
whole precision.
Example (1/3 asScaledDecimal: 1)*3 = 1.0s, not 0.9s.

ScaledDecimals as they are now are just Fraction with a
different printString...
Not very much added value.

Nicolas

On 10/26/2016 09:58 AM, Nicolas Cellier wrote:



    2016-10-26 9:14 GMT+02:00 stepharo mailto:steph...@free.fr>>:

Hi nicolas

So what is the solution? We can integrate fast a
solution.
I would really like to see them fix in Pharo 60.
I'm writing a book for newbie and this is the third
time I change one chapter
so may be I should stop and throw away this chapter.


1) for Fraction:

round: numberOfWishedDecimal
v := 10 raisedTo: numberOfWishedDecimal.
^ ((self * v) rounded / v) asFloat

or just replace asFloat if you wish to remain exact:

round: numberOfWishedDecimal
v := 10 raisedTo: numberOfWishedDecimal.
^ ((self * v) rounded / v) asScaledDecimal:
numberOfWishedDecimal

2) for Float, it is in 15471:

round: numberOfWishedDecimal
| v maxNumberOfDecimals |
maxNumberOfDecimals := self class precision - 1 -
(self exponent max: self class emin).
maxNumberOfDecimals < numberOfWishedDecimal ifTrue:
[^self].
v := 10 raisedTo: numberOfWishedDecimal.
^ ((self asFraction * v) rounded / v) 

Re: [Pharo-dev] [Bloc] Hierarchy of BiEvent

2016-10-26 Thread stepharo

Hi Glenn

Now I understand.

So can you copy and paste this mail into the class comment of the 
BlEvent root.


We should really document such design decision.

Stef

Le 26/10/16 à 19:25, Glenn Cavarlé a écrit :

Hi Stef,


stepharo wrote

OSWindow cannot be the only one backend for Bloc so Bloc events cannot be
based on OSEvents.

Why that?

Because it is OS"Window" and many devices don't have window and sometime
don't have SDL too.
If tomorrow, OSWindow become something like OSDirectMedia with support for
many kind of devices and backends, my answer will be completely different
and in this case you will be right.
So, right now OSWindow is used in Bloc for what it is, a nice windowing
library based on SDL/OpenGL.


stepharo wrote

I do not get why on android we cannot map android event to OSWindowEvents
And do not have duplication in Bloc.

Maybe it is possible, maybe not, maybe it is just inconsistent with the rest
of OSWindow in its current state.
Clearly, I don't know and you? In doubt, i prefer to keep the possibility to
use another backend.


stepharo wrote

So then it means that OSWindowEvents are not useful.
But to me this is bloc events that are not needed.

I don't understand what you mean.
The question is not what is the more useful event hierarchy.
The question is why we cannot use OSWindow events directly in Bloc right
now.

The answer is:

- because many events do not exist in SDL and are consequently not managed
by OSWindow.
- because OSWindow events are not design to be used in a scene graph
- because some information related to the scene graph are missing in the
OSWindow event hierarchy.

If you want to improve OSWindow in this way, this mean that part of Bloc has
to be moved in OSWindow because:
- you need a dispatch/handling mechanism
- you need a scene graph
- you need to generate high-level events (click, drag, focus,...) depending
on nodes in the scene graph

Personally, if something has to be done, I would prefer the opposite: to
move OSWindow in Bloc ;).
  



stepharo wrote

OSWindow is already used in other projects and these users will not be
happy
if we remove OSEvents ;).

who?

I know that Ronie uses OSWindow for Woden.
As i said, if everybody is ok, we can merge OSWindow in Bloc and we can just
keep the existing BlEvent hierarchy.

As explained, it is not a stupid duplication, many things in Bloc events
would have no sense in OSWindow events.
I would like also to mention that we are discussing about a justified
duplication of a hierarchy which have to be changed maybe every 3 years if
magically new events are added in SDL...
It is known that it i not perfect to duplicate things but it is localized
and today i don't have alternative solution that does not includes to
redo/brake OSWindow.


But if you have a concrete solution to avoid that and that does not requires
1000 times more developments than updating the "duplicated" hierarchy once
in 2 years, i'm on it ! ;)


Regards,
Glenn.




-
Glenn Cavarlé
--
View this message in context: 
http://forum.world.st/Bloc-Hierarchy-of-BiEvent-tp4920209p4920294.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.







Re: [Pharo-dev] [Bloc] Hierarchy of BiEvent

2016-10-26 Thread stepharo



Le 26/10/16 à 20:40, Denis Kudriashov a écrit :


2016-10-26 19:45 GMT+02:00 Glenn Cavarlé >:



Yes, your are right.
What i mean is that it could be interesting if:
[ SDLEvent => BlEvent ]   is substantially faster than  [ SDLEvent =>
OSEvent => BlEvent ].
If the difference is not significant, i think that does not
justify to not
benefit from OSWindow abstractions even if sometime they bring
nothing more.


If you already thought about Announcements performance and produce 
optimized alternative then I think it is critical to get events fast.

Now we have 10 variables which are decoded from int by bit operations:

leftShift rightShift leftAlt rightAlt leftCtrl rightCtrl leftCmd
rightCmd capsLock numLock

And then Bloc encodes them back to int. So for any event we have 20 
operations and it is not just primitive calls.
Also OSEvent creation produces own garbage for internal structures 
which also take time and memory.


But for me most important is how maintain both hierarchies. You answer 
Stef that nothing will change over events during years (nobody invent 
new one or not often).
But such argument could never be valid. Code is used, it could has 
bugs, it could be improved by itself. People will always need to work 
with this code, at least to read it. And it is difficult with two 
hierarchies which are managed by double dispatch. Try to follow how 
concrete BlEvent is produced.


And there is already some problem. I investigated deeply what happens 
in sdl about modifiers and buttons. It is not easy. But I see that 
some information becomes lost.
And Bloc also not provides full information from original objects 
(modifiers and buttons).
So to fix these issues one needs to modify both hierarchies. First he 
needs to decide how decode modifiers from SDL and then how to encode 
them into Bloc bits.
And I am sure new issues will be found again and again. It is normal 
process.


So denis you suggest that Bloc uses directly SDLEvents.
This would make sense from your analysis.







Re: [Pharo-dev] roundTo: strange behavior

2016-10-26 Thread stepharo



Le 26/10/16 à 14:52, Nicolas Cellier a écrit :

Sorry for being slow minded,
yes of course financial apps is exactly the case where round: would be 
usefull and NEEDS to be exact.


so what is the solution?
I'm lost again.


Hi Nicolas,
yes, i know. suppose you calc some financial thing and one
intermediate result will be in $. you have to round this
Fraction-result  to 2 decimals. now you use this to further calc
basepoints as the final result. you have to convert this to 3
decimals. looking at this final result with 2 decimals can be be
irritating for a moment, if you debug the calcs. and  btw i
never use scaledDecimals.
werner


On 10/26/2016 02:06 PM, Nicolas Cellier wrote:



2016-10-26 13:11 GMT+02:00 test mailto:wkass...@libello.com>>:

Hi Nicolas,
regarding rounding Fractions:
i use fractions if i want to get an exact result (eg for
comparing the result with Float calculations). if #round:
returns a Float all further calcs (with Fractions) will get
contaminated, since the rest will become Floats too. Hence
the "asScaledDecimal: numberOfWishedDecimal" seems better to
me, but i wonder why these transformations at the end are
necessary at all? just for the looks? i'd suppose every
person, who knows how to use Fractions, also knows how to
append a #asScaledDecimal: to a result by himself, should he
want that.

taking as an example financial calcs that first use 2
decimals. occasionaly the final result will be basepoints,
often small ones like 0.003. with scaledDecimals the result
would be (ok, look like) 0 since scaledDecimals also
contaminate the calc. of course one could correct this simply
with an #asScaledDecimal:3 at the end. nevertheless a first
look at the zero result would surprise me for a tenth of a
second.
werner


Hi Werner,
I don't know the purpose of round: at all.
Most often this kind of message was used before printing probably
because lack of versatile formatted print messages.
In Squeak I replaced most usages of roundTo: by
printShowing(Max)DecimalPlaces:.
Now if it has been added in Pharo and other languages, there must
be some use cases I presume.
Maybe the analysis could be carried on these use cases?

Beware, converting a Fraction asScaledDecimal will NOT round.
Only the printString is rounded, but the number keeps its whole
precision.
Example (1/3 asScaledDecimal: 1)*3 = 1.0s, not 0.9s.

ScaledDecimals as they are now are just Fraction with a different
printString...
Not very much added value.

Nicolas

On 10/26/2016 09:58 AM, Nicolas Cellier wrote:



    2016-10-26 9:14 GMT+02:00 stepharo mailto:steph...@free.fr>>:

Hi nicolas

So what is the solution? We can integrate fast a solution.
I would really like to see them fix in Pharo 60.
I'm writing a book for newbie and this is the third time
I change one chapter
so may be I should stop and throw away this chapter.


1) for Fraction:

round: numberOfWishedDecimal
v := 10 raisedTo: numberOfWishedDecimal.
^ ((self * v) rounded / v) asFloat

or just replace asFloat if you wish to remain exact:

round: numberOfWishedDecimal
v := 10 raisedTo: numberOfWishedDecimal.
^ ((self * v) rounded / v) asScaledDecimal:
numberOfWishedDecimal

2) for Float, it is in 15471:

round: numberOfWishedDecimal
| v maxNumberOfDecimals |
maxNumberOfDecimals := self class precision - 1 - (self
exponent max: self class emin).
maxNumberOfDecimals < numberOfWishedDecimal ifTrue: [^self].
v := 10 raisedTo: numberOfWishedDecimal.
^ ((self asFraction * v) rounded / v) asFloat

or if Fraction already answers a Float:

round: numberOfWishedDecimal
| maxNumberOfDecimals |
maxNumberOfDecimals := self class precision - 1 - (self
exponent max: self class emin).
maxNumberOfDecimals < numberOfWishedDecimal ifTrue: [^self].
^ self asFraction round: numberOfWishedDecimal

It's slower than current implementation, but will round
exactly to the nearest Float.
It's possible to have faster implementation up to 22
decimals if you provide a fused-multiply-accumulate primitive...










Re: [Pharo-dev] roundTo: strange behavior

2016-10-26 Thread stepharo



Hi Nicolas,
regarding rounding Fractions:
i use fractions if i want to get an exact result (eg for comparing
the result with Float calculations). if #round: returns a Float
all further calcs (with Fractions) will get contaminated, since
the rest will become Floats too. Hence the "asScaledDecimal:
numberOfWishedDecimal" seems better to me, but i wonder why these
transformations at the end are necessary at all? just for the
looks? i'd suppose every person, who knows how to use Fractions,
also knows how to append a #asScaledDecimal: to a result by
himself, should he want that.

taking as an example financial calcs that first use 2 decimals.
occasionaly the final result will be basepoints, often small ones
like 0.003. with scaledDecimals the result would be (ok, look
like) 0 since scaledDecimals also contaminate the calc. of course
one could correct this simply with an #asScaledDecimal:3 at the
end. nevertheless a first look at the zero result would surprise
me for a tenth of a second.
werner


Hi Werner,
I don't know the purpose of round: at all.
Most often this kind of message was used before printing probably 
because lack of versatile formatted print messages.
In Squeak I replaced most usages of roundTo: by 
printShowing(Max)DecimalPlaces:.

So what is the definition of printShowingMaxDecimalDigit:?
I have the impression that there is a confusion between the rounding a 
number and the printing of his value in a given format.

we can deprecate roundTo: if necessary.

Now if it has been added in Pharo and other languages, there must be 
some use cases I presume.

You mean roundTo: no idea.


Maybe the analysis could be carried on these use cases?

Beware, converting a Fraction asScaledDecimal will NOT round.
Only the printString is rounded, but the number keeps its whole precision.
Example (1/3 asScaledDecimal: 1)*3 = 1.0s, not 0.9s.

ScaledDecimals as they are now are just Fraction with a different 
printString...

Not very much added value.

Nicolas

On 10/26/2016 09:58 AM, Nicolas Cellier wrote:



2016-10-26 9:14 GMT+02:00 stepharo mailto:steph...@free.fr>>:

Hi nicolas

So what is the solution? We can integrate fast a solution.
I would really like to see them fix in Pharo 60.
I'm writing a book for newbie and this is the third time I
change one chapter
so may be I should stop and throw away this chapter.


1) for Fraction:

round: numberOfWishedDecimal
v := 10 raisedTo: numberOfWishedDecimal.
^ ((self * v) rounded / v) asFloat

or just replace asFloat if you wish to remain exact:

round: numberOfWishedDecimal
v := 10 raisedTo: numberOfWishedDecimal.
^ ((self * v) rounded / v) asScaledDecimal: numberOfWishedDecimal

2) for Float, it is in 15471:

round: numberOfWishedDecimal
| v maxNumberOfDecimals |
maxNumberOfDecimals := self class precision - 1 - (self
exponent max: self class emin).
maxNumberOfDecimals < numberOfWishedDecimal ifTrue: [^self].
v := 10 raisedTo: numberOfWishedDecimal.
^ ((self asFraction * v) rounded / v) asFloat

or if Fraction already answers a Float:

round: numberOfWishedDecimal
| maxNumberOfDecimals |
maxNumberOfDecimals := self class precision - 1 - (self
exponent max: self class emin).
maxNumberOfDecimals < numberOfWishedDecimal ifTrue: [^self].
^ self asFraction round: numberOfWishedDecimal

It's slower than current implementation, but will round exactly
to the nearest Float.
It's possible to have faster implementation up to 22 decimals if
you provide a fused-multiply-accumulate primitive...







Re: [Pharo-dev] [Bloc] Hierarchy of BiEvent

2016-10-26 Thread stepharo



Le 26/10/16 à 16:58, Glenn Cavarlé a écrit :

Denis Kudriashov wrote

I can't take it. Duplication is always bad. There is no reason for it.

I agree, is always bad if there is no real reason to duplicate but i think
there is a real argument for Bloc.
OSWindow cannot be the only one backend for Bloc so Bloc events cannot be
based on OSEvents.

Why that?

We need also a backend for mobile devices with a completely different
implementation than the OSWindow one.
OSWindow is not adapted for non-window-based platforms like mobiles.
For example, on Android, we have to deal with activities and to convert
Android events to Bloc events.


So then it means that OSWindowEvents are not useful.
But to me this is bloc events that are not needed.
I do not get why on android we cannot map android event to OSWindowEvents
And do not have duplication in Bloc.

We have then
SDL events
-> OSWindowEvent - Bloc
Android event

And BlOSWindowEventHandler will work directly with SDL event with full
access to raw event data. No need for intermediate level

It is interesting only if performances are substantially improved.
Because it is also duplication, you duplicates in Bloc the OSWindow
conversion code without any added value.
Moreover, this does not prevent the duplication of Event hierarchy.
OSWindow is already used in other projects and these users will not be happy
if we remove OSEvents ;).

who?

It is clear that every layer has a cost which should not be neglected.
But right now, i think this cost is counterbalanced by the possibility to
move transparently on different windowing backends.
I'm ok if everybody wants to merge Bloc and OSWindow as a single project but
I doubt this is the case.

Regards,
Glenn.






-
Glenn Cavarlé
--
View this message in context: 
http://forum.world.st/Bloc-Hierarchy-of-BiEvent-tp4920209p4920265.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.







Re: [Pharo-dev] [Bloc] Hierarchy of BiEvent

2016-10-26 Thread stepharo



Le 26/10/16 à 15:35, Denis Kudriashov a écrit :

Hi Glenn. Thank's for answer.

2016-10-26 13:29 GMT+02:00 Glenn Cavarlé >:


More generally, i think that, to stay consistent, Bloc should not
reuse
directly (and everywhere) some part of underlying libraries even
if sometime
these parts seems to match directly.


I can't take it. Duplication is always bad. There is no reason for it.


+1


I think we just don't need OSEvent's.


That I'm not sure. Having a nice layer is nice but I do not get why two.


Real low level is SDL events hierarchy.
And OSSDL2WindowHandle built OSEvent's from them:

OSSDL2WindowHandle>>handleNewSDLEvent: sdlEvent

^ sdlEvent accept: self


But we can delegate this processing to osWindow
osWindow handleNewSDLEvent: sdlEvent

which then will call eventsHandler of given window.
And BlOSWindowEventHandler will work directly with SDL event with full 
access to raw event data. No need for intermediate level.







Re: [Pharo-dev] [Bloc] Hierarchy of BiEvent

2016-10-26 Thread stepharo




More generally, i think that, to stay consistent, Bloc should not reuse
directly (and everywhere) some part of underlying libraries even if sometime
these parts seems to match directly.
I do not understand why duplication is a good approach. I would prefer 
to enhance OSWindowEvents

because the low level events are SDLEvents.


We have to take care about dependencies between layers.
The gain was obvious during the migration from Athens to Sparta.


I do not see the point.



Regards,
Glenn.



-
Glenn Cavarlé
--
View this message in context: 
http://forum.world.st/Bloc-Hierarchy-of-BiEvent-tp4920209p4920239.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.







Re: [Pharo-dev] roundTo: strange behavior

2016-10-26 Thread stepharo

Hi nicolas

So what is the solution? We can integrate fast a solution.
I would really like to see them fix in Pharo 60.
I'm writing a book for newbie and this is the third time I change one 
chapter

so may be I should stop and throw away this chapter.

You see I'm not good in math so even if I try hard I will not have a 
good solution.

This is the same for marcus and most people in our team.
I reopened these issues.

Stef



2016-10-25 23:22 GMT+02:00 stepharo <mailto:steph...@free.fr>>:


Ok for the advice

Now round: aNumberOfDigits seems to work fine.

Stef



No it's not, but issues are timing out too fast ;)
https://pharo.fogbugz.com/f/cases/15471/Can-t-round-Float-fmax-to-2-decimal-places
https://pharo.fogbugz.com/f/cases/15472/Fraction-rounding-to-n-decimal-places-is-inexact
https://pharo.fogbugz.com/f/cases/15473/Float-round-to-n-decimal-places-is-not-in-agreement-with-printShowingDecimalPlaces

I hate to say that, but try in python, they got it right...


Le 25/10/16 à 11:05, Henrik Johansen a écrit :

+1.

Unless you're dealing with fixed precision* entities, it's
usually better to specify digits to display in printing methods
themselves (#printShowingDecimalPlaces: & friends in base image).
As per previous discussions around this that arise every second
year or so, rounding the number itself (as long as we're dealing
with floats) will never work as you want reliably.

Cheers,
Henry

* And in that case, you'd use ScaledDecimals


On 23 Oct 2016, at 7:08 , p...@highoctane.be
<mailto:p...@highoctane.be> wrote:

I use the Printf package for that.

v := 65.456.
'With 2 decimal digits: %5.2f, or 3 like this: %6.3f'
printf: {v. v}.

With 2 decimal digits: 65.45, or 3 like this: 65.456

It is in http://www.smalltalkhub.com/#!/~philippeback/HOExtras
<http://www.smalltalkhub.com/#%21/%7Ephilippeback/HOExtras>

Printf

I am just used to C printf and well, I like the way it works.

Phil







Re: [Pharo-dev] [Ann] Stack Android VM

2016-10-26 Thread stepharo
I want to thank Inria to have listen to me (and it was not that simple) 
to let Santiago


work on that. So please use it and show us that you use it.


Stef


Le 23/10/16 à 22:03, Santiago Bragagnolo a écrit :
   Still far from production. But since i would happy to have some 
feedback, I'm happy to show you some progress on the android VM. Not 
yet release. But we have already a way of compiling and deploying an 
image into an android device.


  You can check it in this repo github.
https://github.com/sbragagnolo/pharo-vm/

  The building steps are detailed on the README-Android.md file.


  Building the Stack AndroidVM

1.

Download the sources fromgithub


git clone --depth=1https://github.com/sbragagnolo/pharo-vm
cd  pharo-vm
2.

Set-up your environment: This script will download the SDK
installer and NDK R10

cd  android/scripts
./setupAndroidEnvironment.st

This script downloads the content from

  * 
'http://dl.google.com/android/repository/android-ndk-r10e-linux-x86_64.zip'.
  * 'http://dl.google.com/android/android-sdk_r24.4.1-linux.tgz'.

After this process you should have available the environment
variables ANDROID_NDK_HOME and ANDROID_SDK_HOME. Ensure this by
checking your .bashrc file at the user's home directory.

3.

Create a new image: this image will be created by pointing to this
local git repository

cd  android/scripts
./newImage.st
4.

Link sources to the build folder: The Android vm relies on a Java
wrapper. This sources must be accessible from the build folder.

cd  android/scripts
./linkSources.st
5.

Generate the sources of the stack vm: This script executes the
generator of the image created on int the 3rd step.

cd  android/scripts
./generateStackAndroidMake.st
6.

Generate the resource image for deployment: This script download
and suites up an image for deployment on the folder
build/assets/SmalltalkRessources

cd  android/scripts
./newResourceImage.st

This image created in this point is downloaded with it related VM
for editing and loading the code you want to deploy, or configure
the things you want.

7.

The VM compilation: This script generates the libraries with the
VM code.

cd  build
./build.sh
8.

The Java wrapper compilation and Android Application packaging

cd  build
./package.sh
9.

Installing into your device. If you want to generate an APK file
with your custom name, you will need to deal with the
AndroidManifest.xml before runing the package.sh script :)

cd  build/bin
adb install -r StackActivity-debug.apk


- Im currently working on the JIT version of the VM, that still 
avoiding me :).

 But you have as well the instruction on the same README-Android.me file.


 Santiago










Re: [Pharo-dev] [ANN] Scale

2016-10-25 Thread stepharo

Yes you both are are right.

This is why

- we started to work on making sure that we can configure an image 
to be silent (no logging on changes)


- we should have a way to save / launch configured images.


Stef


Le 25/10/16 à 09:03, p...@highoctane.be a écrit :

Python has virtualenv, where one can install its own little world.
There is no reason we couldn't have an equivalent where a base scale 
image is copied and updated with whatever we feel like.


http://docs.python-guide.org/en/latest/dev/virtualenvs/

Phil

On Tue, Oct 25, 2016 at 5:59 AM, Ben Coman > wrote:


On Mon, Oct 24, 2016 at 5:48 PM, Denis Kudriashov
mailto:dionisi...@gmail.com>> wrote:
> Really nice project, Santiago.
>
> I have few questions:
>
> - what "system saveAfterRun" actually do?
>
> As I understand it saves image when script completes. Imaging
during script
> I loaded Seaside. Does this command makes Seaside accessible
from any scale
> scripts?

Image persistence is one of Pharo's most useful features, but I think
its a liability for a system scripting environment.  As a
philosophical point, Python/Ruby (somewhat) guarantee scripts start
with the same state each time they are run.  I believe this is an
important attribute for system scripting.  "saveAfterRun" seems
detrimental to that because you can break the environment for other
scripts, and you can't just reset state by deleting you script.  Also
its harder to share scripts since dependencies are not recorded in the
script if the system state has changed.  Python/Ruby handle this via a
module import/require facility.  Perhaps Scale could provide a
facility to install a Configuration, then export it via Fuel as a
"module" that could be imported into Scale scripts. Loading via Fuel
should be fast enough (??) that Seaside could be accessible from any
Scale script without too much runtime overhead. (I'll add this as an
Issue if discussion indicates interest).

cheers -ben


>
> - system execute: aString into: anImageBundle
>
> What is anImageBundle here?
>
> - What you think to make scripts working as workspace? All
undeclared
> variables will be added to environment automatically. And in case of
> saveAfterRun they will became accessible from any scale scripts.
>
>
> 2016-10-23 20:34 GMT+02:00 Santiago Bragagnolo
> mailto:santiagobragagn...@gmail.com>>:
>>
>> Hi everybody.
>>
>> We are officially releasing a first version of scale.
>>
>> Scale is a command line handler that is there for making easier
the life
>> of the people that uses scripting in linux. As such, we only
tested it so
>> far in linux. It will be for sure easy to adapt it to mac
because its a
>> *nix, but not for windoze.
>>
>> IMPORTANT REMARK: scale is not meant to develop applications,
it is meant
>> to develop scripts in Pharo, to be launched from the command
line. This
>> means that scale does not provide a top level syntax to declare
classes or
>> methods: people should do that as any normal Pharo application.
Scale should
>> be used to invoke such applications.
>>
>> When would you use scale?
>>   - For example, to replace some bash scripts used for common
boring tasks
>> (and you are using python or ruby there :P)
>>   - Another example, would be when you want to replace bash
scripts that
>> chain things like:
>> ./pharo eval --save "something"
>> ./pharo eval --save "other something"
>> ...
>>
>> Github: https://github.com/guillep/Scale

>> Oneliner to install: (note it needs sudo)
>>
>>  wget -O-
>>
https://raw.githubusercontent.com/guillep/Scale/master/setupScale.sh

| sudo
>> bash
>>
>>
>> In the repository there is some user level documentation based
on examples
>> and a list of available methods on the magical variable
system.  There are
>> many examples as well on the repository.
>>
>> Last but not least, I'm using this project in others two
projects, where
>> it proof it self quite powerful what keeps me on maintaining Scale.
>>
>> These projects are:
>>
>> Pharo Android VM building
https://github.com/sbragagnolo/pharo-vm

>>
>>  Here I use it for automating the creation of a
>>* new building image,
>>* the creation of new resource image (for deploying on
the android
>> apk),
>>* linking the android sources into the building directory
>>* generating the code from the console
>>
>> MakrosTool https://github.com/sbragagnolo/Mak

Re: [Pharo-dev] roundTo: strange behavior

2016-10-25 Thread stepharo

Ok for the advice

Now round: aNumberOfDigits seems to work fine.

Stef


Le 25/10/16 à 11:05, Henrik Johansen a écrit :

+1.

Unless you're dealing with fixed precision* entities, it's usually 
better to specify digits to display in printing methods themselves 
(#printShowingDecimalPlaces: & friends in base image).
As per previous discussions around this that arise every second year 
or so, rounding the number itself (as long as we're dealing with 
floats) will never work as you want reliably.


Cheers,
Henry

* And in that case, you'd use ScaledDecimals

On 23 Oct 2016, at 7:08 , p...@highoctane.be 
 wrote:


I use the Printf package for that.

v := 65.456.
'With 2 decimal digits: %5.2f, or 3 like this: %6.3f'
printf: {v. v}.

With 2 decimal digits: 65.45, or 3 like this: 65.456

It is in http://www.smalltalkhub.com/#!/~philippeback/HOExtras 



Printf

I am just used to C printf and well, I like the way it works.

Phil




Re: [Pharo-dev] [REMEMBER] TechTalk tomorrow 16UTC

2016-10-24 Thread stepharo

Dale

The client desktop of discord is quite nice. I opened it and I'm logged 
if you want to try to find someone.


Stef



Le 24/10/16 à 16:35, Dale Henrichs a écrit :
Hmmm... since Esteban sent the email at 1 am my time and this _is_ 
tomorrow for me ... but perhaps Esteban means Tuesday? since I think 
this is still _today_ in Europe?


Dale


On 10/24/16 7:31 AM, Dale Henrichs wrote:
Since time is short (for me) and I still have to get out ouf bed, 
shower eat and maybe get into the office before the meeting ... could 
someone drop me an email with the details I need to find and install 
(?) discord and find the techtalk ... I'll be out of pocket for about 
an hour getting ready --- as this is short notice (for me) ---


Thanks,

Dale

On 10/24/16 12:58 AM, Esteban Lorenzano wrote:

Hello fellow pharoers,

The time has come (1 month passes so fast!). And tomorrow we will be 
handling another TechTalk.

This time we propose to talk about the new Bootstrap process.

For this, I’d ask Guille, Pavel and/or Christophe to be present. 
They are the ones actually working on it, so we’ll all learn from 
what they have to say :)


Meeting will be handled with discord, as last time.

And as always, this will also be a place to ask anything about pharo 
development (statuses, proposals, etc., etc., etc.)


See you tomorrow !

Esteban











Re: [Pharo-dev] [ANN] Scale

2016-10-24 Thread stepharo

Guille

I could not really understand the three points below.

I have some questions:

- "Scale introduces a new command line handler to manage scripts. " do 
you mean a separate way of managing command lines?


- "syntax sugar to script" which one?

the #! ...

"Scale requires TaskIt and OSSubprocess to provide easy-to-use 
interaction with the system. Should all this be part of Pharo"


- to me this is ok to get it separated but I believe that we should 
really think about that because to me Pharo should support exactly such 
kind of programs. Also if TaskIt enhance for real the concurrency model 
then why not using to support better Pharo?



Stef


Le 24/10/16 à 11:09, Guillermo Polito a écrit :

Hi all,

and thanks Santi for rescuing Scale from the Limbo :).

I saw already some discussions pointing to this thread indirectly. I 
want to answer some philosophical aspects, just to remove some burden 
from Santi who is the real one that should take credit for pushing 
this to the light ^^.


1) Why scale and not "pharo scripting". I saw an email from Norbert 
about this.


Well, I remember we discussed this with Santi a couple of years ago 
about this, when we started and brainstormed about it, but I am not 
able to remember the exact details right now. But, I can still think 
about some arguments in favor of the current decision (which we may 
not keep in the future, hey :))


- First, Pharo is different from ruby and python in terms of 
deployment. In ruby and python, you have the main libraries that are 
shared and your application is deployed locally as files. We can think 
that the script becomes the application. In Pharo, to write an 
application we need to interact and change with the environment. Thus 
we cannot share it. You can think about scale as a read-only pharo 
environment deployed in your machine for scripting purposes.
- Second, Scale is Pharo, but not only. Scale introduces a new command 
line handler to manage scripts. Scale introduces an interpreter that 
is the one that is in charge of executing the code, provide special 
bindings and syntax sugar to scripts (see e.g. the 'system' instance 
in scripts). Scale requires TaskIt and OSSubprocess to provide 
easy-to-use interaction with the system. Should all this be part of 
Pharo? Well I do not know but I prefer to keep it as a separate 
entity. Maybe we can call it a separate distribution, installation or 
whatever.


- Third, if it is a matter of naming (which I think it is), something 
that comes out of the second point is that


 #! /usr/bin/local/scale => #! /usr/bin/local/pharo scale

or better => #! /usr/bin/env pharo scale ?

2) We would appreciate if feedback is not lost in the mailing list but 
is converted in issues instead:


https://github.com/guillep/Scale/issues

Fell free to contribute, provide feedback or even check the code, it 
is really a simple and short project.

It was nice that Santi implemented scale installation in scale :)

Cheers,
Guille

On Sun, Oct 23, 2016 at 11:04 PM, p...@highoctane.be 
 > wrote:


Ok thanks, that will do for me.

Phil

On Sun, Oct 23, 2016 at 10:11 PM, Santiago Bragagnolo
mailto:santiagobragagn...@gmail.com>> wrote:

Thanks Phil! That's not easy to do now, Is mean to be a
feature for the next version.

By the moment you have to add the variable to SCScriptRunner
and initialize the value maybe in initialize.

This SCScriptRunner is the context of execution of the script.



On Sun, 23 Oct 2016 at 21:48 p...@highoctane.be
 mailto:p...@highoctane.be>> wrote:

Ah, this is just *beautiful*

Thank you thank you thank you for making this available.

Question: How is one creating a new scripting object and
making it available? (like system etc).

Phil





On Sun, Oct 23, 2016 at 8:34 PM, Santiago Bragagnolo
mailto:santiagobragagn...@gmail.com>> wrote:

Hi everybody.

We are officially releasing a first version of scale.

Scale is a command line handler that is there for
making easier the life of the people that uses
scripting in linux. As such, we only tested it so far
in linux. It will be for sure easy to adapt it to mac
because its a *nix, but not for windoze.

*IMPORTANT REMARK*: scale is not meant to develop
applications, it is meant to develop scripts in Pharo,
to be launched from the command line. This means that
scale does not provide a top level syntax to declare
classes or methods: people should do that as any
normal Pharo application. Scale should be used to
invoke such applications.

When would you use scale?

Re: [Pharo-dev] roundTo: strange behavior

2016-10-23 Thread stepharo

Thanks because roundUpTo: did not make it either :)


Le 23/10/16 à 18:45, Peter Uhnak a écrit :

I usually use 12.221 round: 2 "12.22".

Peter

On Sun, Oct 23, 2016 at 06:38:47PM +0200, stepharo wrote:

3.1479 roundUpTo: 0.01 is what I was looking for.


Stef



Le 23/10/16 à 18:35, stepharo a écrit :

I see.

I writing a little example for my new newbies book

now how can get only two digits after the .


Stef


Le 23/10/16 à 18:23, Thierry Goubier a écrit :

I think that's called 'welcome to the wonderfull world of
floating points approximations' and not a bug :(

See unums/Gustafson for something more interesting on the subject.

Thierry

2016-10-23 18:16 GMT+02:00 stepharo mailto:steph...@free.fr>>:

Hi

I'm wondering if we do not have a bug here

12.221 roundTo: 0.1
 "12.201"

12.221 roundTo: 0.01
 "12.22"


Stef










Re: [Pharo-dev] roundTo: strange behavior

2016-10-23 Thread stepharo

3.1479 roundUpTo: 0.01 is what I was looking for.


Stef



Le 23/10/16 à 18:35, stepharo a écrit :


I see.

I writing a little example for my new newbies book

now how can get only two digits after the .


Stef


Le 23/10/16 à 18:23, Thierry Goubier a écrit :
I think that's called 'welcome to the wonderfull world of floating 
points approximations' and not a bug :(


See unums/Gustafson for something more interesting on the subject.

Thierry

2016-10-23 18:16 GMT+02:00 stepharo <mailto:steph...@free.fr>>:


Hi

I'm wondering if we do not have a bug here

12.221 roundTo: 0.1
 "12.201"

12.221 roundTo: 0.01
 "12.22"


Stef









Re: [Pharo-dev] roundTo: strange behavior

2016-10-23 Thread stepharo

I see.

I writing a little example for my new newbies book

now how can get only two digits after the .


Stef


Le 23/10/16 à 18:23, Thierry Goubier a écrit :
I think that's called 'welcome to the wonderfull world of floating 
points approximations' and not a bug :(


See unums/Gustafson for something more interesting on the subject.

Thierry

2016-10-23 18:16 GMT+02:00 stepharo <mailto:steph...@free.fr>>:


Hi

I'm wondering if we do not have a bug here

12.221 roundTo: 0.1
 "12.201"

12.221 roundTo: 0.01
 "12.22"


Stef







[Pharo-dev] roundTo: strange behavior

2016-10-23 Thread stepharo

Hi

I'm wondering if we do not have a bug here

12.221 roundTo: 0.1
 "12.201"

12.221 roundTo: 0.01
 "12.22"


Stef




Re: [Pharo-dev] new text model / TxText [was Re: [ANN] Sparta v1.1]

2016-10-23 Thread stepharo

Is there no way Igor can finish this up?


Not that I know.
I did not get why Igor went totally off like that.


Phil


Le 23 oct. 2016 12:19, "stepharo" <mailto:steph...@free.fr>> a écrit :



Hi Stef,

We are not throwing away anything. The goal is not to produce
a new model, the goal is to find one that matches the
requirements.

Don't play with words.

We already learnt a lot from TxText, but it has limitations in
how to deal with things that are not only text.

I can imagine.

We have no intention of producing an unfinished text model :).

Me neither with igor and txText yet life decided otherwise. You
see I spent at 10 months of salary on txText.

  This is a critical component for us. Please let us work for
a couple of months and we get back with news.

Cheers,
Doru


On Oct 22, 2016, at 8:31 PM, stepharo mailto:steph...@free.fr>> wrote:

Hi aliaksei

I thought that you were just changing the internal
representation of txText to use Ropes
and building on top of / improving txText
I did not think that you were throwing away all the work
igor did. Because he spent a lot of time

designing the text model and making it is scalable - and
now I read that apparently it was not scalable enough.
I'm wondering what will happen if suddenly you disappear:
we will get two unfinished textmodel
and use an old one? When do you think that you will have a
working usable by other for real text model?
Stef

Le 22/10/16 à 12:29, Aliaksei Syrel a écrit :

As Doru already mentioned text editor is an important
part of the tools. There are some requirements a text
editor should fulfil.

• Support of large files ( >> 100mb)
• Support of large pieces of text located in
memory
• Allow developers to embed visual elements
(pictures, interactive elements, custom elements)
• Support of more sophisticated layouts rather
than line-based. For example columns.
• Line breaking
• Text wrapping
• Hyphens
• Should be fast
Tests show that TxText model is very nice for basic
cases, works well for "normal" use.
However, when it comes to extreme cases linked list of
spans just fails, while rope shows great performance -
and it also scales.

Cheers,
Alex

On 19 October 2016 at 23:51, Denis Kudriashov
mailto:dionisi...@gmail.com>>
wrote:

2016-10-19 18:06 GMT+02:00 Aliaksei Syrel
mailto:alex.sy...@gmail.com>>:
  - Added initial text support, for instance rendering
and high precision measurement.

I look at code and it seems you implemented another
one new text model? Why you not use TxText?

--
www.tudorgirba.com <http://www.tudorgirba.com>
www.feenk.com <http://www.feenk.com>

"Some battles are better lost than fought."












Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

2016-10-23 Thread stepharo

In the bug tracker

https://pharo.fogbugz.com/f/cases/18650/VTermOutputDriver

https://pharo.fogbugz.com/f/cases/18649/

we got a lot of problems because the monkey and our build process were 
using the api we wanted to change.


So now we are making the changes one by one.

I hope to work on it during the next sprint.


Stef



Le 23/10/16 à 11:31, p...@highoctane.be a écrit :

Where?

On Sun, Oct 23, 2016 at 10:42 AM, stepharo <mailto:steph...@free.fr>> wrote:


Note that all the work on making sure that the image is not
writing files
when it is on read only mode is part of making coral installable
on unix.
Now if people wants coral they can join the effort.

stef






Re: [Pharo-dev] new text model / TxText [was Re: [ANN] Sparta v1.1]

2016-10-23 Thread stepharo



Hi Stef,

We are not throwing away anything. The goal is not to produce a new model, the 
goal is to find one that matches the requirements.

Don't play with words.


We already learnt a lot from TxText, but it has limitations in how to deal with 
things that are not only text.

I can imagine.

We have no intention of producing an unfinished text model :).
Me neither with igor and txText yet life decided otherwise. You see I 
spent at 10 months of salary on txText.

  This is a critical component for us. Please let us work for a couple of 
months and we get back with news.

Cheers,
Doru



On Oct 22, 2016, at 8:31 PM, stepharo  wrote:

Hi aliaksei

I thought that you were just changing the internal representation of txText to 
use Ropes
and building on top of / improving txText
I did not think that you were throwing away all the work igor did. Because he 
spent a lot of time

designing the text model and making it is scalable - and now I read that 
apparently it was not scalable enough.
I'm wondering what will happen if suddenly you disappear: we will get two 
unfinished textmodel
and use an old one? When do you think that you will have a working usable by 
other for real text model?
Stef

Le 22/10/16 à 12:29, Aliaksei Syrel a écrit :

As Doru already mentioned text editor is an important part of the tools. There 
are some requirements a text editor should fulfil.

• Support of large files ( >> 100mb)
• Support of large pieces of text located in memory
• Allow developers to embed visual elements (pictures, interactive 
elements, custom elements)
• Support of more sophisticated layouts rather than line-based. For 
example columns.
• Line breaking
• Text wrapping
• Hyphens
• Should be fast
Tests show that TxText model is very nice for basic cases, works well for 
"normal" use.
However, when it comes to extreme cases linked list of spans just fails, while 
rope shows great performance - and it also scales.

Cheers,
Alex

On 19 October 2016 at 23:51, Denis Kudriashov  wrote:

2016-10-19 18:06 GMT+02:00 Aliaksei Syrel :
  - Added initial text support, for instance rendering and high precision 
measurement.

I look at code and it seems you implemented another one new text model? Why you 
not use TxText?


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

"Some battles are better lost than fought."











Re: [Pharo-dev] [ANN] Sparta v1.1

2016-10-23 Thread stepharo

Doru

does it mean that right now with Sparta we do not have any fallback?

Stef


Le 21/10/16 à 15:41, Tudor Girba a écrit :

Hi Clement,

Thanks for raising this question.

In short, Sparta is inspired from Athens and it has a similar structure. So, 
there is an in-image interface of the canvas, and there is a concrete 
implementation through the plugin (based on Moz2D). To target a completely 
in-image rendering, it is certainly possible to implement a BitBlt backend of 
the Sparta canvas. To implement this part, we would need help.

The goal is indeed to have only one canvas in the default Pharo distribution: 
Sparta. However, this will not happen suddenly. Ideally, when Pharo 6 will be 
released, there will be a beta version of Sparta + Bloc + some tools that will 
be loadable externally. Then my guess is that it will still take another year 
until we get the full development environment working on top of Sparta. So, it 
is to be expected that this transition will take at least 1.5 years during 
which time Athens will still provide the option of running on top of BitBlt.

Does this answer the concern?

But, now my question: Would it not be possible to get the VM to not open a 
window when in headless mode?

Cheers,
Doru


On Oct 21, 2016, at 2:23 PM, Clément Bera  wrote:



On Thu, Oct 20, 2016 at 9:07 AM, Aliaksei Syrel  wrote:
Hi Stéphane

Indeed, build is broken :)
Yesterday I took a very brief look at bloc and can confirm that development 
version is loadable in Pharo 6 and is completely Sparta based. (all examples 
work for me)

You are right, live environment on embedded systems is great goal to achieve. 
Sparta must not prevent pharo from getting there. It is true that plugin is 
relatively big (windows 7mb, osx 15mb, linux 18mb). However, it is all-in-one 
build and size can be reduced dramatically.

As I understand, Pharo for PC should not make any assumptions about user's 
hardware. If gpu accelerated backend can not be used there should be still a 
performant fallback backend which also needs a fallback that is guaranteed to 
work even on Personal Calculators. (Taschenrechner). That is why library is so 
big. For example for mac and windows Sparta is shipped with 3 (!) backends that 
together build fallback chain, for instance on windows: direct2d1.1, skia, 
cairo. Compiling library for mac without Skia reduces binary size from 15mb to 
10mb. Removing GL package and leaving only software backends may reduce size 
even more.

It is a bit different on embedded systems, since hardware configuration is 
already known and there is no need to have so many fallback backends. Library 
itself allows developers to add new exotic backends quite easily.

Let's take Pharo6 for mac. It is shipped with the following libs:
Cairo (1.4mb) + Pixman (2.8mb) + Freetype (0.8mb) = 5mb

Moz2D is self contained and does not require any additional libs.
Moz2D = 15mb, Moz2D without Skia = 10mb. Moz2D without Skia and GL = ? 
(estimate around 6-7mb).

As you can see we get almost the same numbers :)

Yeah but none of the libs (Cairo, Pixman, FreeType) are required to run Pharo, 
they're required only if you use them. I compile VMs without such libraires and 
Pharo works just fine as a development environment and for simple things like 
web servers. The Squeak VM for example have around 2Mb footprint in total, 
including 1Mb for the C runtime (initialized and uninitialized data, executable 
code) and 1 Mb for the machine code zone and can run most Pharo features just 
fine, including for examples web services and the IDE.

Right now the VM cannot start completely headless, the headless mode just hides 
the main window, so if the main window start-up depends on Sparta, it's not 
possible to run Pharo headless without many Mb of memory footprint.

Which leads the first question...


Is it possible to start your Bloc Pharo image on a 2Mb footprint VM ? By asking 
this question, I imply, if there is no Cairo/Pixman/FreeType/Sparta plugin, can 
the image run headless and can it run UI applications ?

The last problem is that Pharo can currently run UI application like the IDE on 
a 2Mb memory footprint VM. Let's assume Pharo with Bloc/Sparta/etc. can be run 
either headless on a 2Mb memory footprint VM or with a UI on a 7Mb+ memory 
footprint VM. It means now people doing UI would need extra memory, for 
example, in the case of android deployment where the android app includes the 
VM and the image, the app memory consumption at runtime would be at least 5Mb 
bigger.


Is the community ok with this or will we need to maintain both the Sparta 
back-end and a Bloc to BitBlt back-end as a fall-back to run on smaller VMs ?


Cheers
Alex

On Oct 19, 2016 22:16, "stepharo"  wrote:
Hi Aliaksei

It looks gorgeous.
I tried to launch the Bloc image from the CI and it crashes during startup on 
my mac. I reported that to Glenn and Alain but so far I simply cannot see Bloc 
code. Is it working for

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

2016-10-23 Thread stepharo

Note that all the work on making sure that the image is not writing files
when it is on read only mode is part of making coral installable on unix.
Now if people wants coral they can join the effort.

stef



Re: [Pharo-dev] Pharo behind ALLSTOCKER marketplace

2016-10-22 Thread stepharo



- Localization
Our business target is world-wide. So localization is very important
topic. Currently ALLSTOCKER supports 4 languages and we will add
Chinese languages soon.
Translation strings are not only in Smalltalk code, but also in
Mustache templates. So we selected Soup for extracting translatable
strings in those templates.
http://smalltalkhub.com/#!/~PharoExtras/Soup
For managing translations, we use Gettext package.
http://smalltalkhub.com/#!/~PharoExtras/Gettext


Hi masashi

I wrote an email and it got lost so I retyping it.
What I would love is that we improve/clean the international support in 
Pharo.

I have the impression that we should
- remove the stream conversion and language encodings and use Zn
- I remember that usman told us that the support for gettext had 
some problems

but I forgot.
So any input and code to help us on that front would be good.

Stef



Re: [Pharo-dev] [ANN] Sparta v1.1

2016-10-22 Thread stepharo

This is what christophe is doing in cargo.


Stef



Le 22/10/16 à 17:29, p...@highoctane.be a écrit :

Looks like we are on the same wavelength but...

Look how this is done in PHP with Composer:

- simple Json file
- declares repositories
- requires and requiresdev
- uses semver versions

so, 'composer install' will fetch and install deps.

composer update will update deps.

composer.json
{
"name": "zendframework/skeleton-application",
"description": "Skeleton Application for ZF2",
"license": "BSD-3-Clause",
"keywords": [
"framework",
"zf2"
],
"homepage": "http://framework.zend.com/";,
"repositories": [{
"type": "vcs",
"url": "https://github.com/RobLoach/firephp-core";
}],
"require": {
"php": ">=5.5",
"zendframework/zendframework": "~2.5",
"zendframework/zftool": "dev-master",
"firephp/firephp-core": "dev-master",
"videlalvaro/php-amqplib": "^2.5"
},
"require-dev": {
"snapshotpl/zf-snap-event-debugger": "1.*",
"zendframework/zend-developer-tools": "dev-master",
"phpunit/phpunit": "4.8.*"
}
}

In the JS Ecosystem, eg. bower.json

{
  "name": "adsdaq",
  "homepage": "https://github.com/anais-it/adsdaq";,
  "authors": [
"Philippe Back mailto:p...@highoctane.be>>"
  ],
  "description": "adsdaq-frontend",
  "main": "",
  "moduleType": [],
  "license": "Adlogix",
  "private": true,
  "ignore": [
"**/.*",
"node_modules",
"bower_components",
"vendor/bower_components",
"test",
"tests"
  ],
  "dependencies": {
"angular": "~1.4.7",
"restangular": "~1.5.1",
"lodash": "~3.10.1",
"angular-route": "~1.4.7",
"angular-spinner": "~0.8.0",
"angular-bootstrap": "~0.14.3",
"typeahead.js": "~0.11.1"
  }
}


So, basic module names in deps and semver.

The st code you show is more cryptic.

Is there a sweet spot ?

Ston is a great format and is Json compatible if we are careful 
(meaning I can actually use vim and json syntax checkers plugins)


St code is indeed more powerful but it leaves a lot of people in the 
dust with configurations.


What do you think?

Phil




On Sat, Oct 22, 2016 at 3:17 PM, Dale Henrichs 
> wrote:




On 10/22/16 12:04 AM, p...@highoctane.be
 wrote:

We need some easy to use gem-style installer on the command line.

Phil,

Since I am not really familiar with ruby, I'm not sure what you
mean by "gem-style installer on the command line"?

Depending upon what you mean, I think I agree:)

For GsDevKit_home[1], I have arranged for bash scripts that can be
used for building both stones and clients for GemStone. Here are
the example scripts for Tugrik[2]:

|# Create Tugrik stone createStone -u
http://gsdevkit.github.io/GsDevKit_home/Tugrik.ston
 -i Tugrik -l
Tugrik Tugrik 3.3.0 # Create Tugrik Pharo5.0 client createClient
-t pharo tugrik -l -v Pharo5.0 -z
$GS_HOME/shared/repos/Tugrik/.smalltalk.ston|

The Tugrik.ston file is a tODE object looks like the following[1]
when materialized (basically a Metacello load script with
additional info):   ^ TDProjectSpecEntryDefinition new
baseline: 'Tugrik'   repository:

'github://dalehenrich/Tugrik:master/repository'   loads:
#('default'); installScript: '   project install --local
--url=http://gsdevkit.github.io/GsDevKit_home/MongoTalk.ston
  
project clone --https --local Tugrik'; postLoadScript: 'mount

@/sys/stone/dirs/Tugrik/gsdevkit/tode /home tugrik'; status:
#(#'inactive'); locked: false; yourself Their are fields
for comments and a project url as well ... obviously other fields
are possible ... the cool thing about this is that is a
specification for a load rather than a Smalltalk load expression
... which means the repository can easily be re-targetted or the
loads list changed, etc. Since Pharo doesn't have tODE:), I
leverage the SmalltalkCI[4] configuration file for Tugrik[5],
which looks like this:   SmalltalkCISpec {   #loading : [
SCIMetacelloLoadSpec {   #baseline : 'Tugrik',   #load : [

'CI' ],   #onWarningLog : true,   #directory :
'repository',   #platforms : [ #gemstone, #pharo ] }   ],
  #configuring : [ SCIGemStoneServerConfigSpec { 
#defaultSessionName : 'Tugrik',  #platforms : [

#gemstoneClient ] }   ]  } Very similar information, but has
the advantage of being usable in GemStone, Squeak and Pharo ... I
have an option for creating stones using a SmalltalkCI
configuration file as well ... I've been thinking that I could add
a MetacelloProjectLoadSpecification class to Metacello that is
meant to be passed aro

Re: [Pharo-dev] Again about scrolling with a trackpad

2016-10-22 Thread stepharo

Denis

this is why I asked you do improve the FT for spec because like that ALL 
the spec tools


will be fixed in one shot.

Stef


Le 21/10/16 à 16:08, Denis Kudriashov a écrit :

Hi Yuriy.

I just want to say that I feel completely same.
And I am sure that problem with Nautilus. I am working on remote 
browser where I just use FastTable and never saw any problem with 
scrolling.


2016-10-21 15:56 GMT+02:00 Yuriy Tymchuk >:


Ok,

there is a problem that when you use trackpad with pharo and you
scroll something strange happens. And it was documented that when
you scroll sideways it’s registered as ctrl + arrow click and it
switches focus.

Now it seems that on Siera it became worse because now I cannot
normally scroll at all.

Additionally this causes a lot of problems: i.e. when someone
wanted to remove history plugin from nautilus many of people
protested because when your navigation is fucked up during
scrolling you can get back.

Now I started to think: why won’t we simply delete the code that
registers these events. So I have a question, does anybody find
this functionality useful? I find it super frustrating. And if
everyone else does, maybe we can simply remove that.

Also while the time passes, does anybody have any idea on how to
hack Pharo to ignore these events? Because I need to work and I
can not…

Cheers.
Uko






Re: [Pharo-dev] [ANN] Sparta v1.1

2016-10-22 Thread stepharo

Hi aliaksei

I thought that you were just changing the internal representation of 
txText to use Ropes


and building on top of / improving txText

I did not think that you were throwing away all the work igor did. 
Because he spent a lot of time


designing the text model and making it is scalable - and now I read that 
apparently it was not scalable enough.


I'm wondering what will happen if suddenly you disappear: we will get 
two unfinished textmodel


and use an old one? When do you think that you will have a working 
usable by other for real text model?


Stef


Le 22/10/16 à 12:29, Aliaksei Syrel a écrit :
As Doru already mentioned text editor is an important part of the 
tools. There are some requirements a text editor should fulfil.


 1. Support of large files ( >> 100mb)
 2. Support of large pieces of text located in memory
 3. Allow developers to embed visual elements (pictures, interactive
elements, custom elements)
 4. Support of more sophisticated layouts rather than line-based. For
example columns.
 5. Line breaking
 6. Text wrapping
 7. Hyphens
 8. Should be fast

Tests show that TxText model is very nice for basic cases, works well 
for "normal" use.
However, when it comes to extreme cases linked list of spans just 
fails, while rope shows great performance - and it also scales.


Cheers,
Alex

On 19 October 2016 at 23:51, Denis Kudriashov > wrote:



2016-10-19 18:06 GMT+02:00 Aliaksei Syrel mailto:alex.sy...@gmail.com>>:

 - Added initial text support, for instance rendering and high
precision measurement.


I look at code and it seems you implemented another one new text
model? Why you not use TxText?






Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

2016-10-22 Thread stepharo



Le 22/10/16 à 17:21, p...@highoctane.be a écrit :

The st command line handler is pretty much giving the same.

I used scale, it works nicely indeed.

But I want Coral reborn.


me too.
Damien is working on a new command line parser.



Phil

On Sat, Oct 22, 2016 at 12:41 PM, Dimitris Chloupis 
mailto:kilon.al...@gmail.com>> wrote:


This link may interest you command line people , it basically what
I proposed as an idea early on

https://github.com/guillep/Scale 

On Sat, 22 Oct 2016 at 13:20, Dimitris Chloupis
mailto:kilon.al...@gmail.com>> wrote:

I was replying to Thierry saying that we had issues with Pharo
mixing metarepo6 with metarepo5
On Sat, 22 Oct 2016 at 13:11, Esteban Lorenzano
mailto:esteba...@gmail.com>> wrote:



On 22 Oct 2016, at 12:00, Dimitris Chloupis
mailto:kilon.al...@gmail.com>> wrote:

Didn't Esteban fixed metarepo ? I think I remember him
saying that he did.


fixed in what sense?

Esteban






Re: [Pharo-dev] [ANN] Sparta v1.1

2016-10-22 Thread stepharo

Superb Phil.


PS: For the record:

we are working on

- bootstrap core and we are making progress

- Git support

- package manager and distribution building

Now we cannot go faster.

This is not every year that we change the complete representation of 
objects.


Now it was NEEDED and we get Spur and SIsta.

Stef


Le 22/10/16 à 09:04, p...@highoctane.be a écrit :

We need some easy to use gem-style installer on the command line.

Pharo is perfectly usable for any kind of project provided energy is 
poured in.


Things are in flux, yes, and it is frustrating not to have it all 
perfect. So what? If we weren't interested in wild things why would we 
be here after all?


Think long term: 10 years from now, improvements will have been 
massively compounding (not to mention 20).


I hope to have a huge win with Pharo business wise and be able to fund 
a serious team. That's my dream. I am actively working on it.


Pharo can stay relevant for that long I believe. I love the way it 
helps me think. I love the fact that I can look everywhere I want. I 
love the fact that this community has balls. I love to show the magic 
we can do with it. If it all goes nowhere, I do not even mind as I 
have a damn awesome time around here.


Now, I also want a working text model. This feels like a kind of 
psychological roadblock. Like a self sabotage. Let's put that dead rat 
on the table and make something about it.


I like Doru's Pillar editor. I guess the underlying engine will evolve 
to make it faster. Great. Grafoscopio will also be a driving force 
there I believe. Pharo can be superspeedy, no core problem.


Sorry for the rant.

Now back to promoting Pharo in front of Android/Angular/Java people 
this afternoon at http://devfest.be (note that this is the 3rd time I 
show Pharo/Amber there - they could kick me out but do not).


/Phil


On Fri, Oct 21, 2016 at 8:12 PM, Dimitris Chloupis 
mailto:kilon.al...@gmail.com>> wrote:


Actually you are wrong, its not hard to use C libraries from
Pharo. UFFI is not a restart, its a continuation of Nativeboost ,
they are very similar.

Pharo FFI, whether its the old FFI, Alien, Nativeboost or UFFI, is
more or less the same. In the end an FFI is defined by C syntax ,
Pharo UFFI borrows the easy of use of Nativeboost that allows you
to take c functions definition and use them as they are with a
simple copy paste.

Pharo is also is based on very good integration with C , like
Squeak can output its code as C code via the Slang interface
though it comes with some limitations.

The availability of C libraries to Pharo is a reflection of the
community size. Comparing with Ruby is very unfair , as Ruby is
vastly more popular (think in thousand times) , hence why you see
so many C libraries wrapped for Ruby. Of course python kicks Ruby
ass kung fu style with its vastly superior array of C wrapped
libraries.

The moment you decide to use an unpopular language as Pharo then
if you are not prepared to get your hands dirty and you expect
things on your plate like Ruby or Python , then its time to go
back to Ruby or Python.

Pharo is not in flux , its evolving, every new tool or library you
see is an evolution of something else.

We dont need Gems for Pharo, Dale has done a great job with
Metacello, its easy to make a pharo project in git/github and have
it install all pharo code and built C libraries wrapped for Pharo.
Just because people are not in the habit of doing this does not
mean its not super easy to be done. For example AFAIK my project
ChronosManager was one of the first project to install from
Catalog Browser not only its Pharo code but also , pngs and audio
files. I made even an autoupdate feature that pings my github repo
to see if there are any new commits and then if so it alerts the
user and give him the ability to download the update with a single
click. All that is metacello.

Metacello is probably one of the best if not the best package
distribution systems out there. Definetly vastly better than
Python's PyPi and Node'js NPM . I cannot praise it enough and I
have no problem criticising Pharo when I must. Dale has done an
amazing job, period.

On the GUI front on the other hand, its messy, no doubt about it.
Morphic is huge, ugly and almost not maintained. Bloc is probably
going to be the next step.

I think the issue here is that we dont have Arduino or Raspberry
Pi guys. Same story for my field, 3d graphics. There is a OpenGL
wrapper and the Wodden graphics engine and nothing else. I and the
author of Woden are the only people here interested into 3d
graphics, he makes Woden, I have made a bridge with Blender Python
, for using Pharo to make Blender addons and I am now in the
process of making a bridge with Unreal Engine.

I dont see why you w

Re: [Pharo-dev] Path >> fullName should not be the same as printString

2016-10-15 Thread stepharo

so how can we make progress?


Stef


Le 14/10/16 à 14:57, Damien Pollet a écrit :
While we're at it, canonicalizing paths at creation time seems wrong 
also:


First because those two expressions do not return the same thing:
Path from: 'a/b/c/../d'
Path * / 'a' / 'b' / 'c' / '..' / 'd'

Second because if c happens to be a symlink, then the operating system 
will not find the same thing as Pharo. The semantics is that you 
follow the symlink first, and follow .. in the directory you end up 
in. So that goes to the parent of the actual directory pointed to by 
the symlink, not back one level in the path.


On 14 October 2016 at 13:59, Sven Van Caekenberghe > wrote:


All this already works (although maybe not perfectly in edge
cases). Consider:

  'file:///C:/Users/tempfile.txt' asUrl.

  'file:///C:/Users/tempfile.txt' asUrl asFileReference.

  FileLocator C / 'Users' / 'tmpfile.txt'.

Where the last two are identical.

Note that relative file URLs do not exist.

> On 14 Oct 2016, at 13:28, Gabriel Cotelli mailto:g.cote...@gmail.com>> wrote:
>
> At least Chrome uses this:
>
> file:///C:/Users/tempfile.txt
>
> On Fri, Oct 14, 2016 at 1:45 AM, Martin McClure
mailto:mar...@hand2mouse.com>> wrote:
> On 10/13/2016 10:35 AM, Damien Pollet wrote:
> Could you give an example what the file:// URLs look like when
they contain a drive letter?
>
> I'm afraid I don't have any Windows machines handy to see what
Internet Explorer does, but as far as I can tell an absolute URL
compliant with RFC 3986 might look something like
>
> file:/c:/foo/bar
>
> A relative URL that fits the URL syntax would be
>
> file:c:/foo/bar
>
> But I'm finding it difficult to tell precisely how RFCs 1738 and
3986 currently interact.
>
> The discussion in this proposed RFC is somewhat interesting:
https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-02
,
as it directly addresses Windows file naming. In appendix B.2, it says
>
> "When mapping a DOS- or Windows-like file path to a URI, use the
drive
>letter (e.g. "c:") as the first path segment. Some
implementations leave the leading slash off before the drive
letter.  "
>
> and appendix C.1 deals with DOS file paths.
>
>
> I hope this is more helpful than it is confusing.
>
> Regards,
>
> -Martin
>
>
>





--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet




Re: [Pharo-dev] [ANN] New release of iceberg

2016-10-15 Thread stepharo

+ 1

This is on my todo  :)


Le 13/10/16 à 20:37, Tudor Girba a écrit :

Hi Nicolas,

Great work!

I will test it again. I kindly ask everyone else to follow the call and test 
this release. Ideally, create a repository on GitHub and play with it.

It is important to get this piece as stable as possible to make Git part of the 
default Pharo experience.

Cheers,
Doru



On Oct 13, 2016, at 2:25 PM, Nicolas Passerini  wrote:

Hi, we are releasing a new version of Iceberg, with several new features and 
bugfixes. I would't yet say that is 100% production ready, but it is close, so 
I want to invite you to test it and provide feedback.

You can install it by doing:

Metacello new
   baseline: 'Iceberg';
   repository: 'github://npasserini/iceberg';
   load.

More installation instructions and documentation can be found at 
https://github.com/npasserini/iceberg.

Some of the new features in this version are:
- Allow to commit several packages together in the same commit.
- Show diffs for incoming and outgoing commits (i.e. before push/pull you can 
browse the difference between the remote and the local versions).
- New History view allows to see any commit in any branch and compare it to the 
current loaded version.
- Better support for interacting code loaded outside Iceberg (smaltalkhub, 
filetree, gitfiletree, etc).
- From the diff view, revert changes or browse them (i.e. open a Nautilus on 
the changed class/method).
- Automatically update presentations on code / repository changes.
- Integration with Metacello, i.e. after installing Iceberg you do something 
like

Metacello new

   
baseline: 'TaskIt'

;
   
repository: 'github://sbragagnolo/taskit'

;
   load.


(By default) it will be loaded using iceberg (there is a setting to avoid it if 
you prefer traditional behavior.

- Improved handling of git errors.
- Improved performance for several operations.
- Improved documentation.
- ... and several bug fixes and other minor improvements (please look at 
https://github.com/npasserini/iceberg/milestone/7?closed=1 for more details).


Please do not hesitate to contact me if you have any doubts.

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

"Reasonable is what we are accustomed with."








Re: [Pharo-dev] [ANN] New release of iceberg

2016-10-13 Thread stepharo



Le 13/10/16 à 19:02, Esteban Lorenzano a écrit :

in principle, Iceberg is meant to work on Pharo6+
No idea about backward compatibility (it shouldn’t be so hard either…)


No ressources for that.
First iceberg should work for Pharo 60.
Everything else is a bonus.


Esteban

On 13 Oct 2016, at 19:00, Hernán Morales Durand 
mailto:hernan.mora...@gmail.com>> wrote:


Hi Nicolas,

After installing it in Pharo 5.0 (#50761, Win 7) and clicking World 
Menu -> Tools -> Iceberg

I got the Exception in the screenshot attached.


2016-10-13 9:25 GMT-03:00 Nicolas Passerini >:


Hi, we are releasing a new version of Iceberg, with several new
features and bugfixes. I would't yet say that is 100% production
ready, but it is close, so I want to invite you to test it and
provide feedback.

You can install it by doing:

Metacello new
baseline: 'Iceberg';
repository: 'github://npasserini/iceberg';
load.

More installation instructions and documentation can be found at
https://github.com/npasserini/iceberg
.

Some of the new features in this version are:
- Allow to commit several packages together in the same commit.
- Show diffs for incoming and outgoing commits (i.e. before
push/pull you can browse the difference between the remote and
the local versions).
- New History view allows to see any commit in any branch and
compare it to the current loaded version.
- Better support for interacting code loaded outside Iceberg
(smaltalkhub, filetree, gitfiletree, etc).
- From the diff view, revert changes or browse them (i.e. open a
Nautilus on the changed class/method).
- Automatically update presentations on code / repository changes.
- Integration with Metacello, i.e. after installing Iceberg you
do something like

Metacello  new
   baseline:  'TaskIt';
   repository:  'github://sbragagnolo/taskit';
   load.


(By default) it will be loaded using iceberg (there is a setting
to avoid it if you prefer traditional behavior.

- Improved handling of git errors.
- Improved performance for several operations.
- Improved documentation.
- ... and several bug fixes and other minor improvements (please
look at
https://github.com/npasserini/iceberg/milestone/7?closed=1
 for
more details).


Please do not hesitate to contact me if you have any doubts.









Re: [Pharo-dev] About icon: and iconNamed:

2016-10-13 Thread stepharo

Denis

You can have a look the changes I did. There is more work to be done but 
I started.


https://pharo.fogbugz.com/f/cases/19201/iconNamed-part-4

What I see is that a command hierarchy is clearly missing because 
SmartSuggestion, Glamour reimplement the same.


Stef



Le 13/10/16 à 17:30, Denis Kudriashov a écrit :


2016-10-13 17:19 GMT+02:00 Ben Coman >:


Is most of that expense come from passing the same Form over a
link multiple times?  I vaguely wonder if content-addressable
caching would help there. 



You see: current state requires such kind of tricks. But if users 
always work with icon names it will not the case completely.


But anyway, wouldn't a remote browser work at a higher level that
being a remote UI?  and the user want to use their local theme
rather than that from the remote image? 



I want to do it like this. But now classes define concrete form which 
should be used in UI. I would call it "no late binding for icons".




[Pharo-dev] itemIcon: and Spotter

2016-10-13 Thread stepharo

Doru

It would be nice to take some action here too.

I would like to remove the Smalltalk ui icons iconNamed:

spotterMonticelloWorkingCopyFor: aStep

aStep listProcessor
title: 'Monticello Working Copy';
allCandidates: [ Array with: self workingCopy ];
itemIcon: [ Smalltalk ui icons iconNamed: #versionControlIcon ];
filter: GTFilterSubstring




Re: [Pharo-dev] About icon: and iconNamed:

2016-10-13 Thread stepharo

So I'm trying to think ;)

menuOn: aBuilder
"Specify the menu used when writing text."


(aBuilder item: #'Find...' translated)
keyText: 'f';
selector: #find;
icon: (Smalltalk ui icons iconNamed: #smallFindIcon)

>

menuOn: aBuilder
"Specify the menu used when writing text."


(aBuilder item: #'Find...' translated)
keyText: 'f';
selector: #find;
icon: #smallFindIcon

Now I do not really like to have a symbol or an icon.


icon: aSymbol

aSymbol asIcon but we could have the provider

So for now I will finish the effort.

have

icon: anIcon and

iconNamed:


Stef
On Oct 13, 2016, at 1:03 PM, stepharo <mailto:steph...@free.fr>> wrote:




Thanks!

Just a question: How about adding an extension

Symbol>>asIcon
^ … look up the icon

Form>>asIcon
^ self


what if you want to have side by side two different themes to compare 
the best icons

choices?


This is a valid concern, but I do not understand how this would work 
if the only thing you pass in iconName: is just one symbol:


act: aBlock iconName: *aSymbol* entitled: aString

So there needs to be a lookup. This lookup will depend on the current 
icon theme. So, you could open on window with one theme, switch the 
theme and then open another window. Or did I misunderstand something?


My idea was that we leave the public API of Glamour to be:

act: aBlock icon: *aSymbolOrForm* entitled: aString

and then if you want to play with things, you can also explicitly pass 
one icon or another (beside relying on the default lookup behavior).


What do you think?

Doru





In this way we do not have to change the external interface, and 
only the internal implementation has to send an “asIcon” before 
using it?


Cheers,
Doru



On Oct 12, 2016, at 10:33 PM, stepharo <mailto:steph...@free.fr>> wrote:


I'm adding

act: aBlock iconName: aSymbol entitled: aString
   self act: aBlock icon: (self iconNamed: aSymbol) entitled: aString

and

act: aBlock iconName: aSymbol on: aCharacter entitled: aString
   self act: aBlock icon: (self iconNamed: aSymbol) on: aCharacter 
entitled: aString


and others 


--
www.tudorgirba.com <http://www.tudorgirba.com>
www.feenk.com

"Every thing has its own flow."












--
www.tudorgirba.com <http://www.tudorgirba.com>
www.feenk.com

"We are all great at making mistakes."












Re: [Pharo-dev] About icon: and iconNamed:

2016-10-13 Thread stepharo

So I'm trying to think

menuOn: aBuilder
"Specify the menu used when writing text."


(aBuilder item: #'Find...' translated)
keyText: 'f';
selector: #find;
icon: (Smalltalk ui icons iconNamed: #smallFindIcon)

>

menuOn: aBuilder
"Specify the menu used when writing text."


(aBuilder item: #'Find...' translated)
keyText: 'f';
selector: #find;
icon: #smallFindIcon


Now I do not really like to pass a symbol.

icon: aSymbol

aSymbol asIcon

But we cannot plug a provider

So for now I would like to continue


Stef


what if you want to have side by side two different themes to compare 
the best icons

choices?


This is a valid concern, but I do not understand how this would work 
if the only thing you pass in iconName: is just one symbol:


act: aBlock iconName: *aSymbol* entitled: aString

So there needs to be a lookup. This lookup will depend on the current 
icon theme. So, you could open on window with one theme, switch the 
theme and then open another window. Or did I misunderstand something?


My idea was that we leave the public API of Glamour to be:

act: aBlock icon: *aSymbolOrForm* entitled: aString

and then if you want to play with things, you can also explicitly pass 
one icon or another (beside relying on the default lookup behavior).


What do you think?

Doru





In this way we do not have to change the external interface, and 
only the internal implementation has to send an “asIcon” before 
using it?


Cheers,
Doru



On Oct 12, 2016, at 10:33 PM, stepharo <mailto:steph...@free.fr>> wrote:


I'm adding

act: aBlock iconName: aSymbol entitled: aString
   self act: aBlock icon: (self iconNamed: aSymbol) entitled: aString

and

act: aBlock iconName: aSymbol on: aCharacter entitled: aString
   self act: aBlock icon: (self iconNamed: aSymbol) on: aCharacter 
entitled: aString


and others 


--
www.tudorgirba.com <http://www.tudorgirba.com>
www.feenk.com

"Every thing has its own flow."












--
www.tudorgirba.com <http://www.tudorgirba.com>
www.feenk.com

"We are all great at making mistakes."












Re: [Pharo-dev] About icon: and iconNamed:

2016-10-13 Thread stepharo


what if you want to have side by side two different themes to compare 
the best icons

choices?


This is a valid concern, but I do not understand how this would work 
if the only thing you pass in iconName: is just one symbol:


act: aBlock iconName: *aSymbol* entitled: aString

So there needs to be a lookup. This lookup will depend on the current 
icon theme. So, you could open on window with one theme, switch the 
theme and then open another window. Or did I misunderstand something?


The idea is that all the tools: should have an iconProvider and not a 
global lookup (even if the lookup can access a global)



My idea was that we leave the public API of Glamour to be:

act: aBlock icon: *aSymbolOrForm* entitled: aString

and then if you want to play with things, you can also explicitly pass 
one icon or another (beside relying on the default lookup behavior).


What do you think?
I would like to avoid clients to use Symbol >> asIcon it can be an 
internal implementation.




Doru





In this way we do not have to change the external interface, and 
only the internal implementation has to send an “asIcon” before 
using it?


Cheers,
Doru



On Oct 12, 2016, at 10:33 PM, stepharo <mailto:steph...@free.fr>> wrote:


I'm adding

act: aBlock iconName: aSymbol entitled: aString
   self act: aBlock icon: (self iconNamed: aSymbol) entitled: aString

and

act: aBlock iconName: aSymbol on: aCharacter entitled: aString
   self act: aBlock icon: (self iconNamed: aSymbol) on: aCharacter 
entitled: aString


and others 


--
www.tudorgirba.com <http://www.tudorgirba.com>
www.feenk.com

"Every thing has its own flow."












--
www.tudorgirba.com <http://www.tudorgirba.com>
www.feenk.com

"We are all great at making mistakes."












Re: [Pharo-dev] About icon: and iconNamed:

2016-10-13 Thread stepharo



Thanks!

Just a question: How about adding an extension

Symbol>>asIcon
^ … look up the icon

Form>>asIcon
^ self


what if you want to have side by side two different themes to compare 
the best icons

choices?




In this way we do not have to change the external interface, and only the 
internal implementation has to send an “asIcon” before using it?

Cheers,
Doru




On Oct 12, 2016, at 10:33 PM, stepharo  wrote:

I'm adding

act: aBlock iconName: aSymbol entitled: aString
self act: aBlock icon: (self iconNamed: aSymbol) entitled: aString

and

act: aBlock iconName: aSymbol on: aCharacter entitled: aString
self act: aBlock icon: (self iconNamed: aSymbol) on: aCharacter entitled: 
aString

and others 


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

"Every thing has its own flow."












Re: [Pharo-dev] About icon: and iconNamed:

2016-10-12 Thread stepharo

I'm adding

act: aBlock iconName: aSymbol entitled: aString
self act: aBlock icon: (self iconNamed: aSymbol) entitled: aString

and

act: aBlock iconName: aSymbol on: aCharacter entitled: aString
self act: aBlock icon: (self iconNamed: aSymbol) on: aCharacter 
entitled: aString


and others 



  1   2   3   4   5   6   7   8   9   10   >