Re: [Pharo-project] How to define a ConfigurationOf with a #development version that depends on a baseline?

2013-04-07 Thread Marten Feldtmann

Alexandre,

I had the same feeling, when I had to use it starting around 1997 in our 
company :-)


We are now C#'pers, but it is interesting to see, that one item is 
remembered by all persons in our team from the Smalltalk-epoche in our 
company in a friendly way: ENVY.


This was the item, which seem to impressed most of the people - 
especially *after* switching to VS.


Marten

On 07.04.2013 04:48, Alexandre Bergel wrote:

Hi Marten,

Frankly speaking, I find Envy way too complicated. I am using it these days and 
I am really not happy with. If I have to read a book to understand how it 
works, than there is no way I can teach students on how to use it in a 
reasonable amount of time.
Configuration Map, Application, edition, scratch version and many more are way 
too many concepts, in my opinion.


attachment: marten.vcf

Re: [Pharo-project] How to define a ConfigurationOf with a #development version that depends on a baseline?

2013-04-06 Thread Marten Feldtmann
In all the discussions about how to manage/organize Smalltalk code - I 
would like to add, that ENVY (though it's so old) with its config maps, 
applications, prerequisites is a pretty good example how it works.


Take a look at the only available ENVY implementation today (VAST) and 
think about the way they did it in the eighties ...


The ENVY-(concept - not the implementation) is still a master peace in 
this area - even when compared with VS or Eclipse - and it supports the 
power of Smalltalk very much.


There are questionable parts of ENVY and I do not use these parts of it 
very often. But even these questionable parts of ENVY have not been 
better solved by other Smalltalk source code management systems.


I've repositories, which are around 10 years old - and ALL code is still 
there, all versions for all different platforms - down to methods 
differences within a mouse click and the speed within a LAN is so good.



Marten



On Apr 5, 2013, at 11:28 PM, Alexandre Bergelalexandre.ber...@me.com  wrote:


Just a question: Is there any plan for a Metacello 2?


attachment: marten.vcf

Re: [Pharo-project] Deploying without .changes and .sources files

2013-02-07 Thread Marten Feldtmann
The good thing about stackoverflow is, that its an open qa system for 
various languages and a system mentioned there means additional 
advertisement.


I sometimes find myselfs there due to a question and suddenly was 
reading answer for different systems.


Marten


On 07.02.2013 10:08, Marcus Denker wrote:


On Feb 7, 2013, at 10:00 AM, Damien Cassoudamien.cas...@gmail.com  wrote:


Hi,

Norbert asked about the possibility to deploy a pharo image without
.changes and .sources files

http://stackoverflow.com/questions/14737695/is-it-possible-to-deploy-a-pharo-image-without-changes-and-sources-files

Could people participate to the discussion there? I think it is important.



Stackoverflow is just one channel to much for me… I need to controll how this 
or I will do nothing but
just read and filter.

Marcus
attachment: marten.vcf

Re: [Pharo-project] Fwd: Lua scripting with nativeboost?

2012-12-12 Thread Marten Feldtmann

And this is the biggest reason to use Lua as a scripting language.

Marten

On 12.12.2012 10:47, Igor Stasenko wrote:


i think the easiest solution is to run a separate image.
if you want to run in same image, then you have to modify compiler/environment
for sandboxed code, where nothing can sneak through and access private data.


attachment: marten.vcf

Re: [Pharo-project] Fwd: Lua scripting with nativeboost?

2012-12-12 Thread Marten Feldtmann

On 12.12.2012 17:18, Esteban Lorenzano wrote:


IMO, that's non-sense.


 Well, that is a matter of view. I've done this also with Lua and 
VASmalltalk and I did this not because of other Smalltalkers in mind 
using my software, but perhaps of potential end users willing to enhance 
the application in a more known language.


 Because of this I also tried to use Rexx as an extension language, 
which is in my view even more suitable to be used as an embedded 
language - but the market decided to use Lua and not Rexx.


Marten
attachment: marten.vcf

Re: [Pharo-project] I don't agree with DummyXXX

2012-11-21 Thread Marten Feldtmann

Nicht um 1600 Uhr ? Wolltest Du nicht noch Unterlagen rumschicken ?


marten

On 21.11.2012 16:47, Fernando Olivero wrote:

I totally agree.  Dummy does not tell me about the class.

Are there just 3 uses of Dummy in the core?

We should either use Null  or use a specific prefix always, so its form
a consisten pattern.

DummyUIManager - NullUIManager

Fernando

On Wed, Nov 21, 2012 at 4:34 PM, Mariano Martinez Peck
marianop...@gmail.com mailto:marianop...@gmail.com wrote:

 From what I understand, Dummy means something different. I have
using that for class names. More accurate names can be found.
I would rename:

DummyUIManager - HeadlessUIManager
DummySystemProgressItem - NullSystemProgressItem
DummySoundSystem - NullSoundSystem

what do you think? do you have better names?

--
Mariano
http://marianopeck.wordpress.com


attachment: marten.vcf

Re: [Pharo-project] A trend and an unfair comparison about js everywhere

2012-10-16 Thread Marten Feldtmann
With HTML and the upcoming WebSockets standard we will see a shift in 
web programming. Web applications are getting true client server systems 
in a much more difficult environment than a traditional (high-speed, low 
latency) company IT world.


Than on the other hand - and we've seen examples in the smalltalk world 
already - solution will be available to produce desktop apps (using the 
same technology as mentioned above - but in an all-in-one-server app) 
and Internet based web applications.


The base key technologies in this area will be how to handle the client 
approach and what the part of Smalltalk can be here and a way to do data 
exchange between internet database and local database.


The server part ? Well integrate the WebSocket technology by the vendors 
and free Smalltalk projects and you have Smalltalk there.


Marten

attachment: marten.vcf

Re: [Pharo-project] [NB] Speaking about callbacks

2012-09-16 Thread Marten Feldtmann

Me too.

Marten

Am 16.09.2012 20:42, schrieb Stéphane Ducasse:



for what it is worth I like the 3rd form. Now I'm not sure on: is the right 
selector.



attachment: marten.vcf

[Pharo-project] SqueakSource3: ByteString(Object)doesNotUnderstand: #goferReferences

2012-09-11 Thread Marten Feldtmann
When I copy the Gofer source (listed on the project pages) to a Pharo 
1.4 and tries to execute stuff like:


Gofer new
repository: 'http://ss3.gemstone.com/ss/ICU';
package: 'ConfigurationOfICU';
package: 'ICU-Core';
package: 'ICU-NativeBoost-Core';
package: 'ICU-Tests-Core';
package: 'ICU-Tests-NativeBoost';
load

I get an error message:

ByteString(Object)doesNotUnderstand: #goferReferences


Marten
attachment: marten.vcf

Re: [Pharo-project] Fwd: Working with Pharo 1.4/2.0 …

2012-09-06 Thread Marten Feldtmann
Just some additional remarks about the setting framework and how VA has 
it since its latest release.


Due to its source code management (ENVY) each application has its own 
configuration section in a simple ascii based *.ini file. Therefore each

application has a text section like

[name of application]
key = value
...

The developer just write 3 methods on the class side of its application 
class, which more or less do something:


one method defines all possible entries expected in the text files and 
what type it has


one method defines current AND default values for each setting

one method defines how to transfer the values to your application.

That's pretty simple - but also limited - and you copy the 
implementation of these three methods from another application, change 
them according to your needs and that's it.


The documentation describing the Pharo settings framework is 20 pages 
long and offers many more features - I actually do not need. And I do 
not need a GUI to edit my setting values - but for others this might be 
useful. The documentation is not straight forward - three or four pages 
with introductions. And even now I do not know how the settings are 
stored outside the system.


But as I said before - I have not done much work with Squeak/Pharo yet - 
and this only reflects my early impressions when working with this 
system. And I even do not know, if Settings is part of Pharo 1.4 or 
Pharo 2.0. Just to give you an overview of my ideas here.



and another point I want to say about using the system:


Working with VASmalltalk/ENVY the methods called after starting, 
resuming, loading, unloading (and various other events) to each 
class/application are  well documented. I do not find 
documents/informations about this in Pharo/Squeak and this is a very 
important information when initializing an application.


Marten Feldtmann

Am 06.09.2012 17:30, schrieb Sean P. DeNigris:


* Settings – I find this one *really* interesting. Will you highlight the
key differences to VA? Maybe we can improve the framework in Pharo, or at
minimum create a UI that makes things simpler and more straightforward for
you
attachment: marten.vcf

Re: [Pharo-project] Fwd: Working with Pharo 1.4/2.0 …

2012-09-06 Thread Marten Feldtmann
Another hint here: I like the refactoring browser's way: multi-select 
items in the list of attributes and default accessors are created - no 
need to edit the code here. I am in the browser, already looking at this 
class - and then I change the code in the browser.


Marten

Am 06.09.2012 17:30, schrieb Sean P. DeNigris:



* creating accessor methods for instance attributes is not speedy and
takes too much clicks



attachment: marten.vcf

Re: [Pharo-project] [NativeBoost] Question: zero-based or one-based indexes?

2012-09-03 Thread Marten Feldtmann

Igor,

for me it does not matter. I've created my own interface package for all 
base types, array access - and all zero-index based - either for 
Smalltalk-memory or external memory access. That's good enough for
me and my projects. Now I'm waiting for your base package with all these 
new accessor methods.



Marten

attachment: marten.vcf

Re: [Pharo-project] [NativeBoost] Question: zero-based or one-based indexes?

2012-09-02 Thread Marten Feldtmann

Hello Igor,

0-based - because it's oriented towards C structures (and therefore 
memory oriented).


Another way to see this is: it's not an index, its an byte-offset from 
the beginning of the memory. Therefore I would not name the parameter as 
something like index, but more like zeroBasedOffset. By the way: 
VASmalltalk does it the same way.


The same problem might occur, when dealing with pointers to array of 
primitive data types in ByteArray or instances of NBExternalAddress.


Even here I would suggest using zero based index structures - though it 
is contrary to Smalltalk typical 0ne-based array index. In VASmalltalk 
this situation is zero-based access and the parameter is not a byte 
index, but a data element index. And an index of 0 returns the start 
of the array (and the first element).


Marten

Am 03.09.2012 02:28, schrieb Igor Stasenko:

Hi, there


i added a bunch of accessors to ByteArray and NBExternalAddress which
having uniform look:

nbtypeAt:
nbtypeAt: put:

where types are:

{U}Int8/16/32/64
or
Float32/64

the problem is that indexes in ByteArray are 1-based,
but in NBExternalAddress is 0-based.

And there's already different places in code which following these rules.
But i feel like this should be uniform (so same piece of code can be
used for either bytearrays or external addresses),
to avoid confusion and mistakes.

i just not sure which one to leave: 1-based or 0-based ?

 From one side, all collections in smalltalk is 1-based..
but from other side accessing memory at 1-based offset looks also unnatural.

What you think?

attachment: marten.vcf

Re: [Pharo-project] [NativeBoost] 1.4 Bleeeding edge release

2012-09-02 Thread Marten Feldtmann

Hello Igor,

I think, that unifom indexing is a must. The usage/handling of 
NBExternalAddress must be equal to instances of ByteArray: at least as 
long as we have synchronous callouts, where a garbage collector is not 
able to move the byte array around in Smalltalk memory during the callout.


Marten

attachment: marten.vcf