Hi guys
I wanted to let you know that each time you buy a pharo book the small
benefit is given to the association.
Stef
Here is how to load and install DBXTalk in Pharo 3.0:
Gofer new
smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver';
package: 'ConfigurationOfOpenDBXDriver';
load.
#ConfigurationOfOpenDBXDriver asClass loadBleedingEdge.
#NBPharoOpenDBX asClass installAsCurrent.
Cheers,
Doru
This issue was more of a discussion between Camillo and Sven. They never
reached a conclusion, so please take a look. I’ve compiled the transcript below.
The issue isn’t easy to solve and maybe we can just close it as “not important”.
https://pharo.fogbugz.com/f/cases/11536/Add-Stream-printStrin
Hi Kilon,
You error is strange. I use Versionner on Pharo 4.0 without any problem.
If I take a closer look at the stack trace, the error comes from the
MetacelloToolBox when Versionner asks for configuration classes.
What is really strange is that after this message sent, the stack shows the
exe
Well to kepp you updated , because I did not bother replying to my own
thread since none seemed to care or have the same issue as me. I tried on
windows again same error as macos on a fresh image by the way. So I know it
must not be me.
But now with a latest Pharo 4 image i get no errors in both M
I have been told that there are some problem with gitfiletree that make it
not recommended for public consumption and recommendation to newcomers.
I have been using not gitfiletree but filetree alone for the past week for
my project Ephestos, because I am ok commiting to git via terminal/
https:/
I’ve written an implementation of lazily initialized expandable collections
(for OrderedCollection and subclasses only for now), inspired by Alexandre’s
talk at ESUG
(http://www.youtube.com/watch?v=x0YJ2dsZdKg&list=UUO-vBhaKVZf0al-ISMMPvRw). The
implementation is pretty much straight forward bu
Le 19 sept. 2014 à 11:21, kilon alios a écrit :
> Well to kepp you updated , because I did not bother replying to my own thread
> since none seemed to care or have the same issue as me.
I was out of office last days ...
> I tried on windows again same error as macos on a fresh image by the way
Branch: refs/tags/40234
Home: https://github.com/pharo-project/pharo-core
Branch: refs/heads/4.0
Home: https://github.com/pharo-project/pharo-core
Commit: a5347722741a52b59c77091c4af73d0799f8ed57
https://github.com/pharo-project/pharo-core/commit/a5347722741a52b59c77091c4af73d0799f8ed57
Author: Jenkins Build Server
Date: 2014-09-19 (Fri, 19 Sep 2014
On Fri, Sep 19, 2014 at 11:32 AM, kilon alios wrote:
> I have been told that there are some problem with gitfiletree that make it
> not recommended for public consumption and recommendation to newcomers.
>
> I have been using not gitfiletree but filetree alone for the past week for
> my project E
Hi Sebastian,
The DLL's have to be where Pharo VM is or in the subfolder where the other DBX
libs are. If in doubt put
it (temporarily) into C:/Windows/System32 as they will be found always then. No
need to restart the OS but
you should reopen Pharo VM with image.
You can find the missing DLL
Tudor Girba-2 wrote
> package: 'ConfigurationOfOpenDBXDriver';
> load.
> #ConfigurationOfOpenDBXDriver asClass loadBleedingEdge.
configurationOf: 'OpenDBXDriver';
loadVersion: #bleedingEdge.
:)
-
Cheers,
Sean
--
View this message in context:
http://forum.world.st/
Branch: refs/tags/40235
Home: https://github.com/pharo-project/pharo-core
Branch: refs/heads/4.0
Home: https://github.com/pharo-project/pharo-core
Commit: 31716ff672da83deb83bf7f262f0890fd0e105be
https://github.com/pharo-project/pharo-core/commit/31716ff672da83deb83bf7f262f0890fd0e105be
Author: Jenkins Build Server
Date: 2014-09-19 (Fri, 19 Sep 2014
On 2014-09-19 11:35, Max Leske wrote:
- my implementation requires an extra instance variable in
OrderedCollection to store the requested size. This extra instance
variable will break Monticello (and possibly other tools) because
Monticello uses OrderedCollections to load code and the particular
From
http://forum.world.st/Next-version-of-Date-DateAndTime-and-Duration-API-updates-td4778871.html
:
Now in the InBox:
KernelTests-cbc.278.mcz
Kernel-cbc.871.mcz
The tests add in test for expected Duration addition and subtraction from
each other, including the new GenericMonth and GenericY
On 19 Sep 2014, at 13:53, Sean P. DeNigris wrote:
> Tudor Girba-2 wrote
>> package: 'ConfigurationOfOpenDBXDriver';
>> load.
>> #ConfigurationOfOpenDBXDriver asClass loadBleedingEdge.
>
> configurationOf: 'OpenDBXDriver';
> loadVersion: #bleedingEdge.
>
> :)
Yes please.
C
just for the record I have not created any kind of configuration in
Ephestos. The code that you can download from Smalltalkhub or github is the
only thing that lives inside the image. I use Smalltalkhub as a backup for
github repo until I make sure filetree is a reliable way to work with
github and
2014-09-19 13:55 GMT+02:00 Markus Fritsche :
> On 2014-09-19 11:35, Max Leske wrote:
>
> - my implementation requires an extra instance variable in
>> OrderedCollection to store the requested size. This extra instance
>> variable will break Monticello (and possibly other tools) because
>> Montice
Hi Sean,
did you see issue 13229
(https://pharo.fogbugz.com/f/cases/13229/Year-arithmetic-broken)? It adds a new
class AnnualDuration to allow for correct year based arithmetics. It also
introduces floats for seconds (with nano seconds as base).
I guess that issue and your change will conflict
On 19.09.2014, at 14:06, Nicolas Cellier
wrote:
>
>
> 2014-09-19 13:55 GMT+02:00 Markus Fritsche :
> On 2014-09-19 11:35, Max Leske wrote:
>
> - my implementation requires an extra instance variable in
> OrderedCollection to store the requested size. This extra instance
> variable will break
Part of that is in
https://pharo.fogbugz.com/f/cases/13229/Year-arithmetic-broken
Furthermore, I am not so sure all this is a good idea, year/month durations are
not constants and are dealt with differently in many context (say the financial
world).
January 30 + 1 month ?
January 31 + 1 month
Max Leske wrote
> your change
It's not mine. I just scanned the thread from Squeak Dev and was intrigued
because I've run into this limitation (the tension between year/month/etc as
a conceptual ideal, and those entities as a specific number of days in
context) a bunch before
-
Cheers,
Sean
On 19.09.2014, at 14:16, Sven Van Caekenberghe wrote:
> Part of that is in
> https://pharo.fogbugz.com/f/cases/13229/Year-arithmetic-broken
>
> Furthermore, I am not so sure all this is a good idea, year/month durations
> are not constants and are dealt with differently in many context (say t
On 19.09.2014, at 14:16, Sean P. DeNigris wrote:
> Max Leske wrote
>> your change
>
> It's not mine. I just scanned the thread from Squeak Dev and was intrigued
> because I've run into this limitation (the tension between year/month/etc as
> a conceptual ideal, and those entities as a specific
Oops. Didn’t realize that thread was from Squeak dev. So there’s no Pharo
implementation of that change for now anyway.
On 19.09.2014, at 14:35, Max Leske wrote:
>
> On 19.09.2014, at 14:16, Sean P. DeNigris wrote:
>
>> Max Leske wrote
>>> your change
>>
>> It's not mine. I just scanned the
Ok, so I read Chris’ e-mail and I’m intrigued.
Sven, you’re still right about financial months being 30 days for instance but
the thing is that the current implementation seems broken (or inconsisten at
least) and doesn’t honor that case either. *Not* making the change will not
help us either…
2014-09-19 9:16 GMT-03:00 Sven Van Caekenberghe :
> Part of that is in
> https://pharo.fogbugz.com/f/cases/13229/Year-arithmetic-broken
>
> Furthermore, I am not so sure all this is a good idea, year/month durations
> are not constants and are dealt with differently in many context (say the
> fi
Le 19 sept. 2014 à 14:59, Esteban A. Maringolo a écrit :
> Pharo Date/DateAndTime are incremental[1], then all this
> week/month/year operations will simply add/subtract the increment from
> epoch.
>
> The only way to do this in a deterministic way is to have a field based Date.
Yes, it would b
Very cool.
- Do you parse data from a file? If so, what format does that file need to be
in?
- Is the map zoomable to city level (to see connections between Bern and Zürich
for instance)?
Cheers,
Max
On 19.09.2014, at 15:23, Leonel Merino wrote:
> Hi All,
>
> I have been working on a visual
Hi Max,
Thanks !
The input is a CSV file which contains a grid with city names and latency.
Surely you can zoom-in at city level. However, the map only contains
information of the cities that come in the dataset (is not Bern).
Best regards,
Leonel
On 19 Sep 2014, at 15:30, Max Leske wrote:
>
Hi Kilon,
Not sure what you are trying to do.
Try this:
-=-=-=-=-=-=-=-=-=-=-=-=
forms := Form allInstances.
v := RTView new.
t := 1.
e := (RTBitmap new form: [ :index | forms at: index ]) elementOn: t.
v add: e.
v open.
[
50 timesRepeat: [
t := t + 1.
Well… Porting Roassal3d to Woden is almost straightforward :-)
We can help on this.
Effort behind Woden, Roassal, GraphET are not to simply tools. But instead
producing an effective solution for a given problem. So, they will always be
changing :-)
Cheers,
Alexandre
On Sep 14, 2014, at 7:28 A
On 19 Sep 2014, at 14:59, Esteban A. Maringolo wrote:
> 2014-09-19 9:16 GMT-03:00 Sven Van Caekenberghe :
>> Part of that is in
>> https://pharo.fogbugz.com/f/cases/13229/Year-arithmetic-broken
>>
>> Furthermore, I am not so sure all this is a good idea, year/month durations
>> are not consta
Being consistent is of course better (note however that #month does not exist
today, probably because it is hard to define). The double-dispatching is also
good. But I would have to study the actual code in detail to have a better
opinion.
On 19 Sep 2014, at 14:48, Max Leske wrote:
> Ok, so I
This is excellent Leonel!
I’ve tried, but I could not make the visualization work. Apparently you are
using a rather old version of Roassal2. I suggest you to update it to the last
version of Roassal2.
Cheers,
Alexandre
On Sep 19, 2014, at 6:48 AM, Leonel Merino wrote:
> Hi Max,
>
> Thanks
2014-09-19 11:14 GMT-03:00 Sven Van Caekenberghe :
>
> On 19 Sep 2014, at 14:59, Esteban A. Maringolo wrote:
>
>> 2014-09-19 9:16 GMT-03:00 Sven Van Caekenberghe :
>> Pharo Date/DateAndTime are incremental[1], then all this
>> week/month/year operations will simply add/subtract the increment from
On 19 Sep 2014, at 16:31, Esteban A. Maringolo wrote:
> 2014-09-19 11:14 GMT-03:00 Sven Van Caekenberghe :
>>
>> On 19 Sep 2014, at 14:59, Esteban A. Maringolo wrote:
>>
>>> 2014-09-19 9:16 GMT-03:00 Sven Van Caekenberghe :
>>> Pharo Date/DateAndTime are incremental[1], then all this
>>> week
Thanks Alex !
Sure, I’ll do it.
—Leonel
On 19 Sep 2014, at 16:30, Alexandre Bergel wrote:
> This is excellent Leonel!
> I’ve tried, but I could not make the visualization work. Apparently you are
> using a rather old version of Roassal2. I suggest you to update it to the
> last version of Roa
2014-09-19 11:41 GMT-03:00 Sven Van Caekenberghe :
[1] http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e310
>>
>>> Very interesting link, really useful - Thx.
>>
>> At least it makes you understand some pros/cons about date implementations.
>> After reading that I understood why Java's Cal
Branch: refs/tags/40236
Home: https://github.com/pharo-project/pharo-core
Branch: refs/heads/4.0
Home: https://github.com/pharo-project/pharo-core
Commit: 489cbebbe3d9bf20b8370adc3a1647f8e169375f
https://github.com/pharo-project/pharo-core/commit/489cbebbe3d9bf20b8370adc3a1647f8e169375f
Author: Jenkins Build Server
Date: 2014-09-19 (Fri, 19 Sep 2014
On 19.09.2014 15:23, Leonel Merino wrote:
> If you want to load the code:
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Gofer new smalltalkhubUser: 'merino'
> project: 'NetworkLatency';
> package: 'ConfigurationOfNetworkLatency';
> load.
> (ConfigurationO
On 19/09/2014 13:48, Max Leske wrote:
Ok, so I read Chris’ e-mail and I’m intrigued.
Sven, you’re still right about financial months being 30 days for instance but
the thing is that the current implementation seems broken (or inconsisten at
least) and doesn’t honor that case either. *Not* maki
Branch: refs/tags/40237
Home: https://github.com/pharo-project/pharo-core
Branch: refs/heads/4.0
Home: https://github.com/pharo-project/pharo-core
Commit: 9e661910bcd2381958d313ad66631dc0a8cb7d07
https://github.com/pharo-project/pharo-core/commit/9e661910bcd2381958d313ad66631dc0a8cb7d07
Author: Jenkins Build Server
Date: 2014-09-19 (Fri, 19 Sep 2014
This is not yet possible. I would hope we get this to work within the
context of TxText.
Igor got nearly embedded morphs to react to event: we embedded a
simpleButtonMorph in TxText
and we can click on it, delete it... Now there are some problems with
positionning but
it should be fixed soon.
As you could see in the Pillar highlighting support,
Rubric can now handle any syntax highlighting in a rather
straightforward way. You can also easily embed this in a
Glamour browser.
I'll have a look. I find that PluggableTextMorph automa
Take it as a different experience on the GUI side; I know I
invest a lot in the motor skill part of the GUI, and this has
an effect when I switch platform.
It seems to me that you are not comparing the Moose image with the
Pharo image, right? What are you compar
2014-09-19 20:32 GMT+02:00 stepharo :
> This is not yet possible. I would hope we get this to work within the
>> context of TxText.
>>
>
> Igor got nearly embedded morphs to react to event: we embedded a
> simpleButtonMorph in TxText
> and we can click on it, delete it... Now there are some proble
On Sep 19, 2014, at 8:05 AM, Torsten Bergmann wrote:
> In the end I used ODBC package as it is easy to load from the config browser
> and one only has
> to setup an ODBC name
After installing all and getting things sorted, it rejects my connection.
Triplechecked, network settings, server and c
max why not subclassing OrderedCollections?
I’ve written an implementation of lazily initialized expandable collections (for
OrderedCollection and subclasses only for now), inspired by Alexandre’s talk at
ESUG
(http://www.youtube.com/watch?v=x0YJ2dsZdKg&list=UUO-vBhaKVZf0al-ISMMPvRw). The
im
Keep in mind that Monticello is "portable" to other dialects and changing
the internal representation will break Monticello for other platforms ...
FWIW, the implemenation of OrderedCollection in GemStone is very different
than in Pharo or Squeak and it was possible for me to fudge the serializer
Le 19/09/2014 13:36, Sebastian Sastre a écrit :
yes if things where in markdown friendly wiki and git you'll see a pull request
in half a second
I'll think of something
but returning to the dll issue, you mention you endd up using odbc and I see
there are two backends to choose from. The odbc
Hi Sebastian,
I think there are two ways for ODBC'ing from Pharo:
1. one is the one included in DBXTalk, I think I had this running also in the past and added
the glorp adaptor for ODBC. Cant remember why I switched to 2.
2. the ODBC package (on top of FFI) that you can load fro
Le 19/09/2014 23:36, Torsten Bergmann a écrit :
Hi Sebastian,
I think there are two ways for ODBC'ing from Pharo:
1. one is the one included in DBXTalk, I think I had this running also
in the past and added
the glorp adaptor for ODBC. Cant remember why I switched to 2.
The same for me :)
Le 15/09/2014 14:21, kilon alios a écrit :
thanks I am looking at it
is this relevant to pharo ? --> http://en.wikipedia.org/wiki/Visitor_pattern
Hi,
Of course, the only difference between what you will find in
java,dotNet,c++ examples and Smalltalk is that the latter does not
support method
On Fri, Sep 19, 2014 at 1:19 AM, Max Leske wrote:
> This issue was more of a discussion between Camillo and Sven. They never
> reached a conclusion, so please take a look. I’ve compiled the transcript
> below.
>
> The issue isn’t easy to solve and maybe we can just close it as “not
> important”.
Le 15/09/2014 18:23, Eliot Miranda a écrit :
I find this whole discussion depressing. It seems people would rather
put their energy in chasing quick fixes or other technologies instead of
contributing to the work that is being done in the existing VM. People
discuss using LLVM as if the code g
Le 20 sept. 2014 02:11, "Alain Rastoul" a écrit :
>
> Le 15/09/2014 18:23, Eliot Miranda a écrit :
>
>> I find this whole discussion depressing. It seems people would rather
>> put their energy in chasing quick fixes or other technologies instead of
>> contributing to the work that is being done
2014-09-19 20:59 GMT-03:00 Eliot Miranda :
>
>
> On Fri, Sep 19, 2014 at 1:19 AM, Max Leske wrote:
>>
>> This issue was more of a discussion between Camillo and Sven. They never
>> reached a conclusion, so please take a look. I’ve compiled the transcript
>> below.
>>
>> The issue isn’t easy to sol
Le 20/09/2014 02:33, p...@highoctane.be a écrit :
We'll prevail!
What we also need to do is to showcase the Smalltalk workflow and how
nice it is.
We cannot gain mindshare by technical prowess only.
Phil
I totally agree with you,
but I think that those technical advances are vital in curre
63 matches
Mail list logo
