Re: [Pharo-users] Timespan translateToUTC problematic

[Alistair Grant]

On 20 November 2017 at 08:30, Ben Coman  wrote:
> I don't ponder much on Dates, DateTimes etc, but I just had one interesting
> image flash through my head
> and was curious how correct it sounds, or if I'm completely off base.
>
> So who remembers the old arcade game "Moon Buggy" ?
> https://www.youtube.com/watch?v=6EptD9Egf7w
>
> Now imagine that passing beneath your wheels is a hyper-fast terrain of
> DateTime .
> Levels are days marked "A" , "B", "C", "D", "E" at *fixed* points on the
> DateTime terrain, representing when a particular Date begins.
>
> As your day progresses dealing with obstacles in your path the *point* of
> Date separation approaches you.
> In your own timezone you know what Date it is by when your wheels pass over
> a Date marker.

I'm just glad that Bloc is on the way and we have GTInspector so that
in future when I inspect a Date there'll be a tab there that *you*
wrote with a moon buggy flashing lasers to show me what's happening.
:-)


> Now if someone in the US wants to know the date in New Zealand,
> that is like attaching a scanning laser beam to the front of the buggy.
> How far ahead it scans depends on the *difference* between time zones.
> As the DateTime terrain passes beneath your wheels, the fixed Date point
> approaches you, and when it touches your lazer scanner, the Date changes in
> the other timezone.
>
> So the way to find the date in another timezone,
> is not to give a Date a timezone, but rather to add the difference in
> timezones to your DateTime
> to get the DateTime in the target country to compare that with
> timezoneless-Date.

I think that there's still use for representing a date as a timespan,
i.e. a 24 hour period that we can use to find the intersection of
times, etc (in addition to adding a timezone offset to a DateTime to
figure out the date in a different country).  Whether it needs to be a
separate class from Timespan I'm not so sure.

Cheers,
Alistair


> cheers -ben
>
>
>
>
> [1] https://www.youtube.com/watch?v=6EptD9Egf7w
>
>
> On 20 November 2017 at 10:12, David T. Lewis  wrote:
>>
>> Richard,
>>
>> That is a very good explanation, and 100% correct.
>>
>> Dave
>>
>> On Mon, Nov 20, 2017 at 12:30:38PM +1300, Richard A. O'Keefe wrote:
>> > I think the fundamental question is what a Date is supposed
>> > to represent.  I have spent a LOT of time thinking about date
>> > and time classes over the last 10 years, and have come to the
>> > conclusion that it makes no sense to view a Date as a Timespan.
>> >
>> > Let's take an example.
>> > Christmas this year is going to be 2017-12-25 in every country
>> > that uses the Gregorian calendar and observes Christmas at all.
>> > If I ask the question
>> >"Is Christmas on the same date in Utah as it is in Otago?"
>> > I expect to get the answer YES.
>> > But if I ask the question
>> >"Is the span of time *called* Christmas day there same
>> > as the span of time *called* Christmas day here?"
>> > I expect to get the answer NO.
>> >
>> > It's not entirely unlike the way that '95 Hanover Street'
>> > is the same street address in my city as '95 Hanover Street'
>> > in Edinburgh, but they correspond to quite different places.
>> > (Here: the Urgent Doctors; there: serviced apartments.)
>> >
>> > Returning to Dates, I expect something like
>> >   aDate asTimespan: aTimeZone
>> > to return a timespan that might be 23, 24, or 25 hours
>> > (possibly plus an extra second), with *maybe*
>> >   aDate asTimespan
>> > meaning
>> >   aDate asTimespan: TimeZone here
>> >
>> > Naturally the same goes for Weeks, Months, and Years, should
>> > they exist.
>> >
>>
>

Re: [Pharo-users] Timespan translateToUTC problematic

[Ben Coman]

On 20 November 2017 at 14:58, Alistair Grant  wrote:

> On 18 November 2017 at 18:38, Sven Van Caekenberghe  wrote:
> >
> >
> >> On 18 Nov 2017, at 17:46, Alistair Grant  wrote:
> >>
> >> On 17 November 2017 at 14:44, Sven Van Caekenberghe 
> wrote:
> >>> Both interpretation are correct and valid, it is just hard to capture
> them with one class.
> >>>
> >>> In normal human conversation and in the abstract, of course a date is
> just a year/month/date triple. But that is because most people only look at
> this from their own perspective. However, from an international
> perspective, of course it must include time zone info. Remember
> end-of-year/new-year, with all those articles about people in other
> countries partying or having fireworks earlier/later.
> >>>
> >>> Date transitions are different in each time zone, so to talk
> accurately about a date, you need the context of a time zone.
> >>
> >> I don't think this is correct.
> >>
> >> If we take CEST (UTC+1) and AEDT (UTC+11) as an example: From midnight
> >> to 14:00 UTC the dates are the same.  From 14:00 - 24:00 CEST
> >> Australia is one day ahead.
> >>
> >> How can this be interpreted sensibly given only a date?  Unless I'm
> >> missing something, I think Peter is correct and that a Date shouldn't
> >> have any concept of timezone.
> >
> > Inspect and compare the following two Dates:
> >
> > {
> > (DateAndTime fromString: '2018/01/01T00:00:00+11') asDate.
> > (DateAndTime fromString: '2018/01/01T00:00:00+01') asDate
> > }.
> >
> > This is as if you typed 'Date today' at the beginning of next January
> 1st in your timezone or mine. Both print as '1 January 2018'. In some sense
> they are equal (the abstract, context free view), but as a timespan
> [start,stop] interval they are different, they do not include the same
> points in time. By having the timezone in there, the ambiguity is resolved.
> That is because the exact start moment is different:
> >
> > {
> > (DateAndTime fromString: '2018/01/01T00:00:00+11') asUTC.
> > (DateAndTime fromString: '2018/01/01T00:00:00+01') asUTC
> > }.
>
> Sven, thanks for your reply.  I haven't thought about this as much as
> Richard, but came to the same conclusion.
>
> I think your comment about being equal "in the abstract, context free
> view" gets to the core of the issue.
>
> A date can be abstract, i.e. just a day, month and year, or it can be
> a timespan (a 24 hour period starting at a particular timezone).  We
> may know the appropriate timezone when we specify the date, or we may
> not know until we want to use the date.
>
> As an example, take wishing someone happy birthday.  I want to know
> that person's birthday in the abstract.  Each year I will want to
> apply it with timezones, i.e. I'll figure out an appropriate time to
> contact them given my timezone and their's.  Figuring out when to
> contact them certainly doesn't depend on the timezone I was in when I
> recorded their  birthday, or the timezone they were in when they were
> born.  If I want to know if that person and I have the same birthday,
> I won't be taking timezones into account.
>

Nice examples. They made a lot of sense.



>
> Google Calendar has (had?) exactly this problem.  I entered an all day
> event as a reminder for someone's birthday.  When the day came I
> happened to be in a different timezone and their birthday was from 4pm
> one day to 4pm the next.  I don't remember which timezone I was in
> when I added the event, and I'm certainly not interested in figuring
> it out.  Which of the two dates covered by this "one date" is

the correct one?
>

Obviously GodGoog should know this date was associated with a particular
person,
and since they're happy with GG geo-tracking their location, GG should have
adapted.
Sounds like a bug to me.

\
;^)-cheers-ben
/



>
> It should be easy to convert an abstract date to a concrete date, i.e.
> one with a specified timezone, but I think they are two different
> concepts.
>
> Thanks!
> Alistair
>
>
>
>
> > BTW, my ZTimestamp package is an alternative DateAndTime object that is
> (1) always in UTC, and thus contains no timezone and (2) has second
> precision. It is half the size and faster to work with.
> >
> > By using its accompanying ZTimezone class that loads the Olsen DB, you
> do the necessary conversions when presenting to humans. That of course then
> requires the context (current or applicable timezone) to be supplied
> externally.
> >
> > (ZTimezone id: 'Australia/Sydney') gmtToLocal: ZTimestamp now.
> >
> > HTH,
> >
> > Sven
> >
> >> Cheers,
> >> Alistair
> >>
> >>
> >>> Whether that timezone is actually part of the date object is another
> discussion, but there is always the timezone context even if it is implicit
> ('of course I mean my own timezone and not yours').
> >>>
>  On 17 Nov 2017, at 14:19, Peter Uhnák  wrote:
> 
>  Because Date has, by definition, no 

Re: [Pharo-users] Timespan translateToUTC problematic

[Ben Coman]

I don't ponder much on Dates, DateTimes etc, but I just had one interesting
image flash through my head
and was curious how correct it sounds, or if I'm completely off base.

So who remembers the old arcade game "Moon Buggy" ?
https://www.youtube.com/watch?v=6EptD9Egf7w

Now imagine that passing beneath your wheels is a hyper-fast terrain of
DateTime .
Levels are days marked "A" , "B", "C", "D", "E" at *fixed* points on the
DateTime terrain, representing when a particular Date begins.

As your day progresses dealing with obstacles in your path the *point* of
Date separation approaches you.
In your own timezone you know what Date it is by when your wheels pass over
a Date marker.

Now if someone in the US wants to know the date in New Zealand,
that is like attaching a scanning laser beam to the front of the buggy.
How far ahead it scans depends on the *difference* between time zones.
As the DateTime terrain passes beneath your wheels, the fixed Date point
approaches you, and when it touches your lazer scanner, the Date changes in
the other timezone.

So the way to find the date in another timezone,
is not to give a Date a timezone, but rather to add the difference in
timezones to your DateTime
to get the DateTime in the target country to compare that with
timezoneless-Date.


cheers -ben




[1] https://www.youtube.com/watch?v=6EptD9Egf7w

On 20 November 2017 at 10:12, David T. Lewis  wrote:

> Richard,
>
> That is a very good explanation, and 100% correct.
>
> Dave
>
> On Mon, Nov 20, 2017 at 12:30:38PM +1300, Richard A. O'Keefe wrote:
> > I think the fundamental question is what a Date is supposed
> > to represent.  I have spent a LOT of time thinking about date
> > and time classes over the last 10 years, and have come to the
> > conclusion that it makes no sense to view a Date as a Timespan.
> >
> > Let's take an example.
> > Christmas this year is going to be 2017-12-25 in every country
> > that uses the Gregorian calendar and observes Christmas at all.
> > If I ask the question
> >"Is Christmas on the same date in Utah as it is in Otago?"
> > I expect to get the answer YES.
> > But if I ask the question
> >"Is the span of time *called* Christmas day there same
> > as the span of time *called* Christmas day here?"
> > I expect to get the answer NO.
> >
> > It's not entirely unlike the way that '95 Hanover Street'
> > is the same street address in my city as '95 Hanover Street'
> > in Edinburgh, but they correspond to quite different places.
> > (Here: the Urgent Doctors; there: serviced apartments.)
> >
> > Returning to Dates, I expect something like
> >   aDate asTimespan: aTimeZone
> > to return a timespan that might be 23, 24, or 25 hours
> > (possibly plus an extra second), with *maybe*
> >   aDate asTimespan
> > meaning
> >   aDate asTimespan: TimeZone here
> >
> > Naturally the same goes for Weeks, Months, and Years, should
> > they exist.
> >
>
>

Re: [Pharo-users] Timespan translateToUTC problematic

[Alistair Grant]

On 18 November 2017 at 18:38, Sven Van Caekenberghe  wrote:
>
>
>> On 18 Nov 2017, at 17:46, Alistair Grant  wrote:
>>
>> On 17 November 2017 at 14:44, Sven Van Caekenberghe  wrote:
>>> Both interpretation are correct and valid, it is just hard to capture them 
>>> with one class.
>>>
>>> In normal human conversation and in the abstract, of course a date is just 
>>> a year/month/date triple. But that is because most people only look at this 
>>> from their own perspective. However, from an international perspective, of 
>>> course it must include time zone info. Remember end-of-year/new-year, with 
>>> all those articles about people in other countries partying or having 
>>> fireworks earlier/later.
>>>
>>> Date transitions are different in each time zone, so to talk accurately 
>>> about a date, you need the context of a time zone.
>>
>> I don't think this is correct.
>>
>> If we take CEST (UTC+1) and AEDT (UTC+11) as an example: From midnight
>> to 14:00 UTC the dates are the same.  From 14:00 - 24:00 CEST
>> Australia is one day ahead.
>>
>> How can this be interpreted sensibly given only a date?  Unless I'm
>> missing something, I think Peter is correct and that a Date shouldn't
>> have any concept of timezone.
>
> Inspect and compare the following two Dates:
>
> {
> (DateAndTime fromString: '2018/01/01T00:00:00+11') asDate.
> (DateAndTime fromString: '2018/01/01T00:00:00+01') asDate
> }.
>
> This is as if you typed 'Date today' at the beginning of next January 1st in 
> your timezone or mine. Both print as '1 January 2018'. In some sense they are 
> equal (the abstract, context free view), but as a timespan [start,stop] 
> interval they are different, they do not include the same points in time. By 
> having the timezone in there, the ambiguity is resolved. That is because the 
> exact start moment is different:
>
> {
> (DateAndTime fromString: '2018/01/01T00:00:00+11') asUTC.
> (DateAndTime fromString: '2018/01/01T00:00:00+01') asUTC
> }.

Sven, thanks for your reply.  I haven't thought about this as much as
Richard, but came to the same conclusion.

I think your comment about being equal "in the abstract, context free
view" gets to the core of the issue.

A date can be abstract, i.e. just a day, month and year, or it can be
a timespan (a 24 hour period starting at a particular timezone).  We
may know the appropriate timezone when we specify the date, or we may
not know until we want to use the date.

As an example, take wishing someone happy birthday.  I want to know
that person's birthday in the abstract.  Each year I will want to
apply it with timezones, i.e. I'll figure out an appropriate time to
contact them given my timezone and their's.  Figuring out when to
contact them certainly doesn't depend on the timezone I was in when I
recorded their  birthday, or the timezone they were in when they were
born.  If I want to know if that person and I have the same birthday,
I won't be taking timezones into account.

Google Calendar has (had?) exactly this problem.  I entered an all day
event as a reminder for someone's birthday.  When the day came I
happened to be in a different timezone and their birthday was from 4pm
one day to 4pm the next.  I don't remember which timezone I was in
when I added the event, and I'm certainly not interested in figuring
it out.  Which of the two dates covered by this "one date" is
the correct one?

It should be easy to convert an abstract date to a concrete date, i.e.
one with a specified timezone, but I think they are two different
concepts.

Thanks!
Alistair




> BTW, my ZTimestamp package is an alternative DateAndTime object that is (1) 
> always in UTC, and thus contains no timezone and (2) has second precision. It 
> is half the size and faster to work with.
>
> By using its accompanying ZTimezone class that loads the Olsen DB, you do the 
> necessary conversions when presenting to humans. That of course then requires 
> the context (current or applicable timezone) to be supplied externally.
>
> (ZTimezone id: 'Australia/Sydney') gmtToLocal: ZTimestamp now.
>
> HTH,
>
> Sven
>
>> Cheers,
>> Alistair
>>
>>
>>> Whether that timezone is actually part of the date object is another 
>>> discussion, but there is always the timezone context even if it is implicit 
>>> ('of course I mean my own timezone and not yours').
>>>
 On 17 Nov 2017, at 14:19, Peter Uhnák  wrote:

 Because Date has, by definition, no concept of time.
 The only reason why you see it is because someone decided to save a bit of 
 time and reuse implementation.

 If you want to move TZ, you need something that _has_ time. Such as 
 DateAndTime.

 You can also read the comments ...

 Date
> Instances of Date are Timespans with duration of 1 day.

 it represents an entire day, not a particular time point

 DateAndTime
> I represent a point in time or timestamp as 

Re: [Pharo-users] Timespan translateToUTC problematic

[David T. Lewis]

Richard,

That is a very good explanation, and 100% correct.

Dave

On Mon, Nov 20, 2017 at 12:30:38PM +1300, Richard A. O'Keefe wrote:
> I think the fundamental question is what a Date is supposed
> to represent.  I have spent a LOT of time thinking about date
> and time classes over the last 10 years, and have come to the
> conclusion that it makes no sense to view a Date as a Timespan.
> 
> Let's take an example.
> Christmas this year is going to be 2017-12-25 in every country
> that uses the Gregorian calendar and observes Christmas at all.
> If I ask the question
>"Is Christmas on the same date in Utah as it is in Otago?"
> I expect to get the answer YES.
> But if I ask the question
>"Is the span of time *called* Christmas day there same
> as the span of time *called* Christmas day here?"
> I expect to get the answer NO.
> 
> It's not entirely unlike the way that '95 Hanover Street'
> is the same street address in my city as '95 Hanover Street'
> in Edinburgh, but they correspond to quite different places.
> (Here: the Urgent Doctors; there: serviced apartments.)
> 
> Returning to Dates, I expect something like
>   aDate asTimespan: aTimeZone
> to return a timespan that might be 23, 24, or 25 hours
> (possibly plus an extra second), with *maybe*
>   aDate asTimespan
> meaning
>   aDate asTimespan: TimeZone here
> 
> Naturally the same goes for Weeks, Months, and Years, should
> they exist.
> 

Re: [Pharo-users] Timespan translateToUTC problematic

[Richard A. O'Keefe]

I think the fundamental question is what a Date is supposed
to represent.  I have spent a LOT of time thinking about date
and time classes over the last 10 years, and have come to the
conclusion that it makes no sense to view a Date as a Timespan.

Let's take an example.
Christmas this year is going to be 2017-12-25 in every country
that uses the Gregorian calendar and observes Christmas at all.
If I ask the question
   "Is Christmas on the same date in Utah as it is in Otago?"
I expect to get the answer YES.
But if I ask the question
   "Is the span of time *called* Christmas day there same
as the span of time *called* Christmas day here?"
I expect to get the answer NO.

It's not entirely unlike the way that '95 Hanover Street'
is the same street address in my city as '95 Hanover Street'
in Edinburgh, but they correspond to quite different places.
(Here: the Urgent Doctors; there: serviced apartments.)

Returning to Dates, I expect something like
  aDate asTimespan: aTimeZone
to return a timespan that might be 23, 24, or 25 hours
(possibly plus an extra second), with *maybe*
  aDate asTimespan
meaning
  aDate asTimespan: TimeZone here

Naturally the same goes for Weeks, Months, and Years, should
they exist.

Re: [Pharo-users] New Pharo article at The Cohort

[Richard A. O'Keefe]

I'm obviously missing a lot of the context here, but in  my
country (New Zealand) there is something called the
Fair Trading Act.

My understanding from reading the Commerce Commission web
site is that
 - false or misleading representations about goods or
   services or the availability of goods are against the
   law
 - "The penalties for breaching the Act can be severe"
   (Grant Harris).
 - obviously wild exaggerations made to be funny are sort
   of OK, but if anyone falls for them you could find this
   tested in court
 - "Any claims made to bolster the image of a business or
   its products or services must be accurate."
 - "The Act applies even when there was no intention to
   breach the Act".  (Grant Harris again.)

http://www.comcom.govt.nz/fair-trading/fair-trading-act-fact-sheets/claiming-you-re-something-you-re-not/

The Fair Trading Act was passed as part of a program of market
liberalisation and in order to foster competition and market
efficiency, and the majority of the cases have been trader-to-
trader.  Why mention this?  Because it's not just places where
consumer protection is high-ranked that have such laws; it's
also places that are gung-ho about free markets and competition
and want to protect businesses.

Law in the USA varies from state to state.  For California, see
https://www.truthinadvertising.org/california/
(which has a navbar on the right for other states).

Me, I think Pharo is good enough to "sell" on its merits
without any exaggerations.  (If you could combine the great
looks of Dolphin Smalltalk with the great features of Pharo,
drool...)

Re: [Pharo-users] Travis build failing because of bad CRC

[Julien]

So the fix is just to relaunch the build? :-)

Julien

> Le 19 nov. 2017 à 19:56, Cyril Ferlicot D.  a écrit 
> :
> 
> Le 19/11/2017 à 19:54, Julien a écrit :
>> Hello,
>> 
>> I’m trying to set up continuous integration for one of my project but I
>> have an error with the CRC of the VM (see the
>> log https://travis-ci.org/juliendelplanque/PostgreSQLParser/jobs/304401690).
>> 
>> Is it my fault?
>> 
> 
> Not your fault. It happen also randomly on Synectique's CI.
> 
>> Thanks in advance,
>> 
>> Julien
> 
> 
> -- 
> Cyril Ferlicot
> https://ferlicot.fr
> 
> http://www.synectique.eu
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
> 

Re: [Pharo-users] Travis build failing because of bad CRC

[Cyril Ferlicot D.]

Le 19/11/2017 à 19:54, Julien a écrit :
> Hello,
> 
> I’m trying to set up continuous integration for one of my project but I
> have an error with the CRC of the VM (see the
> log https://travis-ci.org/juliendelplanque/PostgreSQLParser/jobs/304401690).
> 
> Is it my fault?
> 

Not your fault. It happen also randomly on Synectique's CI.

> Thanks in advance,
> 
> Julien


-- 
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France



signature.asc
Description: OpenPGP digital signature

[Pharo-users] Travis build failing because of bad CRC

[Julien]

Hello,

I’m trying to set up continuous integration for one of my project but I have an 
error with the CRC of the VM (see the log 
https://travis-ci.org/juliendelplanque/PostgreSQLParser/jobs/304401690 
).

Is it my fault?

Thanks in advance,

Julien

Re: [Pharo-users] New Pharo article at The Cohort

[Offray Vladimir Luna Cárdenas]

Andrew,

Thanks for sharing those articles. Is nice to see that Grafoscopio is
showcased in the "little brother" story. I agreed that most of the
processing could be happening on the edges of the network instead of in
the Big Data centers (Cisco CEO thinks the same, which is not
surprising). I defined such edges as "pocket infrastructures"  which is
an arrangement of tools which are characterized for being simple, self
contained, and working fine on-line and off-line and run in a wide
spectrum of hardware, from USB drives to modest laptops and beyond (and
in between), which contrast sharply with the exclusionary discourse,
infrastructure and practice of "Big Data" and the classical idea of
predicting the future by hyping only a part of it. Using such pocket
infrastructures (as Grafosocpio and Fossil, linked in the previous
mail), we can put in "everybody's pockets" the tools for being a
data/digital citizen, instead in only the places with "deep pockets"
(money, resources, big data centers, monstrous data bases & data sets
and so on), and with some prototypes, like the one of the Panama Papers,
we have showed that is possible to approach in a more inclusive way,
problems that has been approached only from the Big Data perspective.
This also means an alternative way of dealing with data. Instead of
being the data threshing machine that tries to process everything, we
try to "build the magnet to find the needle in the haystack", focusing
on frictionless interconnected data [1] and zooming out from there.

[1]
https://blog.okfn.org/2013/04/24/frictionless-data-making-it-radically-easier-to-get-stuff-done-with-data/


Also was nice to see your philosophical approach to objects and your
conversation with Kay. There he touches aspects that are told also in
the prologue for Stephan's book about Learning programming with robots.

By the way, I have noticed that your post don't include a lot of
external links. For example the part where you mention notebooks could
link to Grafoscopio[2] and the part where you mention agile
visualization could point to Roassal[3]. Any reason for not including
external links? Is that a style choice?

[2] http://mutabit.com/grafoscopio/index.en.html
[3] http://agilevisualization.com/

Cheers,

Offray


On 18/11/17 10:50, Andrew Glynn wrote:
>
> Here’s a list of the articles @ https://medium.com/@dasein42/latest,
> in case any catch your eye:
>
>  
>
> Latest
>
> Go to the profile of Andrew Glynn
>
> Andrew Glynn
>
> Nov 14
>
> “Dynamics Trumps Semantics”: Why Java is Easy to Learn, but Difficult
> to be Good at.
>
>  
>
> Read more…
>
>  
>
>  
>
> Go to the profile of Andrew Glynn
>
> Andrew Glynn
>
> Nov 8
>
> IoT Initiative — “little brother”
>
>  
>
> The core notion behind “little brother” is to overcome the inevitable
> lag between the increase in…
>
> Read more…
>
>  
>
>  
>
> Go to the profile of Andrew Glynn
>
> Andrew Glynn
>
> Nov 7
>
> Software Developer Tooling: Then and Now
>
>  
>
> While my criticisms of current tooling for development are often met
> with an attitude of…
>
> Read more…
>
>  
>
> 6
>
>  
>
> Go to the profile of Andrew Glynn
>
> Andrew Glynn
>
> Nov 5
>
>  
>
> The Inverted Ambiguity of the Post-Modern Public, or Not
>
> Read more…
>
>  
>
>  
>
> Go to the profile of Andrew Glynn
>
> Andrew Glynn
>
> Nov 5
>
> Someone Was Asking About Devops …
>
>  
>
> Someone I know was asking me about devops the other day, particularly
> the number and variety of…
>
> Read more…
>
>  
>
> 5
>
>  
>
> Go to the profile of Andrew Glynn
>
> Andrew Glynn
>
> Nov 5
>
> Reality and the ‘Simple’ True, or the True-in-Itself, or the Truth
>
>  
>
> Read more…
>
>  
>
>  
>
> Go to the profile of Andrew Glynn
>
> Andrew Glynn
>
> Nov 5
>
> What is Intended by the term “Object-Oriented”?
>
>  
>
> Read more…
>
>  
>
> 1
>
> 1 response
>
> Go to the profile of Andrew Glynn
>
> Andrew Glynn
>
> Nov 4
>
> Pharo Smalltalk as a DSL Without a DSL
>
>  
>
> If anyone has written a DSL in Eclipse, for example, simply the base
> projects Eclipse…
>
> Read more…
>
>  
>
> 22
>
>  
>
> Go to the profile of Andrew Glynn
>
> Andrew Glynn
>
> Nov 4
>
>  
>
> Tooling: Design of Meta and Underlying Rationale
>
> Read more…
>
>  
>
>  
>
> Go to the profile of Andrew Glynn
>
> Andrew Glynn
>
> Nov 2
>
>  
>
> How the Results of Disruption Changes the Discussion Between
> Aficionados of Specific Languages and Environments
>
> Read more…
>
>  
>
>  
>
> Go to the profile of Andrew Glynn
>
> Andrew Glynn
>
> Nov 2
>
> Disrupted Software the Disrupted Software Industry Uses to Build
> Disruptive Software
>
> Read more…
>
>  
>
>  
>
> Go to the profile of Andrew Glynn
>
> Andrew Glynn
>
> Nov 2
>
> Software is Virtual; the Virtual is Disruptive; Software Disrupts the
> Development of Software
>
> Read more…
>
>  
>
>  
>
> Go to the profile of Andrew Glynn
>
> Andrew Glynn
>
> Nov 2
>
> 

Re: [Pharo-users] Grease for Pharo7: TBehavior extensions?

[Pavel Krivanek]

2017-11-19 13:28 GMT+01:00 Johan Brichau :

> Hi Pharoers,
>
> We have one failing test for Grease in Pharo7.
> The reason is that Grease extends the TBehavior trait with a method
> #fullName.
>
> I notice this trait is no longer used? Are we supposed to extend Behavior
> directly?
> Overall: what are the plans?
>

Yes, you should extend the Behavior and other TBehavior users directly.

-- Pavel

>
> Some advice would be good so I can keep Grease into shape.
>
> thanks everyone
> Johan
>

[Pharo-users] Grease for Pharo7: TBehavior extensions?

[Johan Brichau]

Hi Pharoers,

We have one failing test for Grease in Pharo7.
The reason is that Grease extends the TBehavior trait with a method #fullName.

I notice this trait is no longer used? Are we supposed to extend Behavior 
directly?
Overall: what are the plans?

Some advice would be good so I can keep Grease into shape.

thanks everyone
Johan

Re: [Pharo-users] How to deploy headless app without changes and source files?

[Sven Van Caekenberghe]

> On 19 Nov 2017, at 01:54, despotadesdibujau  
> wrote:
> 
> I applied the solution of Sven over a minimal image of Pharo and it works!
> I created a script to disable the calls to sources and changes and then I
> deleted those.
> The complete tutorial for use the minimal image is  here
>   

I just wanted to add that NoChangesLog and NoPharoFilesOpener are standard 
parts of Pharo 7 (I forgot when we actually added them).