From marcus.denker at inria.fr  Fri Jun  3 16:36:58 2011
From: marcus.denker at inria.fr (Marcus Denker)
Date: Fri, 3 Jun 2011 16:36:58 +0200
Subject: [sbe-discussion] Pharo by Example German translation: repository
Message-ID: <18D4F942-08BA-41C7-B219-505EBE66ACAB@inria.fr>

Hello,

There is now a repository for a german translation of PBE:

	https://github.com/SquareBracketAssociates/PharoByExample-german

right now this is just a copy of the english text as a starting point.

	Marcus

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.


From x19290 at gmail.com  Tue Jun  7 04:03:40 2011
From: x19290 at gmail.com (Hiroki Horiuchi)
Date: Tue, 07 Jun 2011 11:03:40 +0900
Subject: [sbe-discussion] Want to translate PBE into Japanese
Message-ID: <4DED86FC.7010905@gmail.com>

Hello.

I am a Japanese Smaltalk beginner/programmer. I have read the original
"Pharo by Example" and decided to translate it by Bazaar manner.

I have a github account but do not know how to create repo like
https://github.com/SquareBracketAssociates/PharoByExample-japanese.
Would someone mind helping me?

Regards,

Hiroki Horiuchi

From serge.stinckwich at gmail.com  Tue Jun  7 04:21:16 2011
From: serge.stinckwich at gmail.com (Serge Stinckwich)
Date: Tue, 7 Jun 2011 09:21:16 +0700
Subject: [sbe-discussion] Re: Want to translate PBE into Japanese
In-Reply-To: <4DED86FC.7010905@gmail.com>
References: <4DED86FC.7010905@gmail.com>
Message-ID: <BANLkTinVHQSVoQT-=PMmRm-XpGBhVcGDbQ@mail.gmail.com>

On Tue, Jun 7, 2011 at 9:03 AM, Hiroki Horiuchi <x19290 at gmail.com> wrote:
> Hello.

Dear Hiroki,

> I am a Japanese Smaltalk beginner/programmer. I have read the original
> "Pharo by Example" and decided to translate it by Bazaar manner.

I just create a japanese team in SquareBracketAssociates:
https://github.com/organizations/SquareBracketAssociates/teams
and i add you as a member.

> I have a github account but do not know how to create repo like
> https://github.com/SquareBracketAssociates/PharoByExample-japanese.
> Would someone mind helping me?

I create a japanese repository for the book here:
https://github.com/SquareBracketAssociates/PharoByExample-japanese

You have now to clone the PharoByExample-english on your disk and copy
these file in the new PharoByExample-japanese repository.

Feel free to ask me more information if you want.
Regards,
-- 
Serge Stinckwich
UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
Every DSL ends up being Smalltalk
http://doesnotunderstand.org/

From x19290 at gmail.com  Tue Jun  7 04:58:37 2011
From: x19290 at gmail.com (Hiroki Horiuchi)
Date: Tue, 07 Jun 2011 11:58:37 +0900
Subject: [sbe-discussion] Re: Want to translate PBE into Japanese
In-Reply-To: <BANLkTinVHQSVoQT-=PMmRm-XpGBhVcGDbQ@mail.gmail.com>
References: <4DED86FC.7010905@gmail.com>
	<BANLkTinVHQSVoQT-=PMmRm-XpGBhVcGDbQ@mail.gmail.com>
Message-ID: <4DED93DD.6090503@gmail.com>

On 2011?06?07? 11:21, Serge Stinckwich wrote:
> I just create a japanese team in SquareBracketAssociates:
> https://github.com/organizations/SquareBracketAssociates/teams
> and i add you as a member.
> I create a japanese repository for the book here:
> https://github.com/SquareBracketAssociates/PharoByExample-japanese
>
> You have now to clone the PharoByExample-english on your disk and copy
> these file in the new PharoByExample-japanese repository.
>
> Feel free to ask me more information if you want.
> Regards,

Thank you very much!
--
Hiroki Horiuchi

From stephane.ducasse at free.fr  Tue Jun  7 09:18:38 2011
From: stephane.ducasse at free.fr (stephane ducasse)
Date: Tue, 7 Jun 2011 09:18:38 +0200
Subject: [sbe-discussion] Re: Want to translate PBE into Japanese
In-Reply-To: <4DED86FC.7010905@gmail.com>
References: <4DED86FC.7010905@gmail.com>
Message-ID: <C6694DA2-EEBA-4FC5-BAF0-1D68853522A1@free.fr>

Thanks a lot.
I would love to help you, but I cannot :)

Stef

On Jun 7, 2011, at 4:03 AM, Hiroki Horiuchi wrote:

> Hello.
> 
> I am a Japanese Smaltalk beginner/programmer. I have read the original
> "Pharo by Example" and decided to translate it by Bazaar manner.
> 
> I have a github account but do not know how to create repo like
> https://github.com/SquareBracketAssociates/PharoByExample-japanese.
> Would someone mind helping me?
> 
> Regards,
> 
> Hiroki Horiuchi
> _______________________________________________
> Sbe-discussion mailing list
> Sbe-discussion at iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion
> 


From x19290 at gmail.com  Fri Jun 10 13:29:05 2011
From: x19290 at gmail.com (Hiroki Horiuchi)
Date: Fri, 10 Jun 2011 20:29:05 +0900
Subject: [sbe-discussion] How should we markup Japanese version of PBE?
Message-ID: <4DF20001.8040705@gmail.com>

Hello.

PBE-ja project has just begun. But there is a controversy: How should we
markup it?

There is a strong opinion that markup language itself does not matter,
just contents matter. From this opinion, Someone concludes that it is
possible to separate marking-up from translation. Actually, some people
likely hate marking-up. Another conclusion is that alternative markup
language like Sphinx can/should be used.

Personally, I think the best way is that each translator does laTeX
him/herself. But it does not seem to be a popular opinion.

Dr. Yoshiki Ohshima points that if we adopt another markup language
than laTeX, the appearance of final output will be different from ones
of other laTeX based projects, and that we should confirm if it is
acceptable to you, multi-l10n team.

May I have your opinion?

Regards,

Hiroki Horiuchi


From damien.pollet at inria.fr  Fri Jun 10 15:19:50 2011
From: damien.pollet at inria.fr (Damien Pollet)
Date: Fri, 10 Jun 2011 15:19:50 +0200
Subject: [sbe-discussion] Re: How should we markup Japanese version of PBE?
In-Reply-To: <4DF20001.8040705@gmail.com>
References: <4DF20001.8040705@gmail.com>
Message-ID: <09A87D47-87D9-4ACE-AD98-D4C287C56F33@inria.fr>

On Jun 10, 2011, at 13:29, Hiroki Horiuchi wrote:
> There is a strong opinion that markup language itself does not matter,
> just contents matter. From this opinion, Someone concludes that it is
> possible to separate marking-up from translation. Actually, some people
> likely hate marking-up.

Sure, those people could write the translated text then that could be merged afterwards into the actual document, but that's of course more work for whoever will do that merge. PBE is not a novel with pages and pages of linear text; there are lots of inline examples, figures, references etc...

> Another conclusion is that alternative markup language like Sphinx can/should be used.

Sphinx is the python documentation markup ? Does it really have so many technical advantages over LaTeX, or is it just about someone not willing to learn a new tool ?

Because, unless sphinx handles japanese content especially better than LaTeX, this just seems like NIH syndrome or arguing between Java and C# for programming :)

> Personally, I think the best way is that each translator does laTeX
> him/herself. But it does not seem to be a popular opinion.

If the objection is about the macros and code organization, these are certainly open to improvements, and those will benefit all translations. Note that going to another markup implies you'll have to basically redo all that work from scratch and handle fixes (devil is in the details)

I have no idea how much of a pain it is to use LaTeX for japanese. Do you input UTF-8, or one of the JIS encodings ? Do you have to write TeX hieroglyphs to express many things ?

> Dr. Yoshiki Ohshima points that if we adopt another markup language
> than laTeX, the appearance of final output will be different from ones
> of other laTeX based projects, and that we should confirm if it is
> acceptable to you, multi-l10n team.

Appearance does not really matter that much. Actually the current typography could be simplified. IMHO what's really important is correct references, indexing... as well as being able to follow what's being done on the english version so that the translations are up-to-date.

--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet





From x19290 at gmail.com  Fri Jun 10 15:47:12 2011
From: x19290 at gmail.com (Hiroki Horiuchi)
Date: Fri, 10 Jun 2011 22:47:12 +0900
Subject: [sbe-discussion] Re: How should we markup Japanese version of PBE?
In-Reply-To: <09A87D47-87D9-4ACE-AD98-D4C287C56F33@inria.fr>
References: <4DF20001.8040705@gmail.com>
	<09A87D47-87D9-4ACE-AD98-D4C287C56F33@inria.fr>
Message-ID: <4DF22060.5020709@gmail.com>

Hello.

This English might be worse than I wrote previous time because this is
not well checked by an English expert.

First of all, I must apologize to you and to our team member also.
I chose a word "hate" but it is too strong and must be wrong.

Mr. Umezawa who is now the project Leader has started maintaining a
table including a field to ask if LaTeX is OK, and there is no negative
answer. Six of nineteen members say OK so far.

Sorry I have no more time tonight. To be continued tomorrow...

Regards,

Hiroki Horiuchi


On 2011?06?10? 22:19, Damien Pollet wrote:
> On Jun 10, 2011, at 13:29, Hiroki Horiuchi wrote:
>> >  There is a strong opinion that markup language itself does not matter,
>> >  just contents matter. From this opinion, Someone concludes that it is
>> >  possible to separate marking-up from translation. Actually, some people
>> >  likely hate marking-up.
> Sure, those people could write the translated text then that could be merged afterwards into the actual document, but that's of course more work for whoever will do that merge. PBE is not a novel with pages and pages of linear text; there are lots of inline examples, figures, references etc...
>
>> >  Another conclusion is that alternative markup language like Sphinx can/should be used.
> Sphinx is the python documentation markup ? Does it really have so many technical advantages over LaTeX, or is it just about someone not willing to learn a new tool ?
>
> Because, unless sphinx handles japanese content especially better than LaTeX, this just seems like NIH syndrome or arguing between Java and C# for programming:)
>
>> >  Personally, I think the best way is that each translator does laTeX
>> >  him/herself. But it does not seem to be a popular opinion.
> If the objection is about the macros and code organization, these are certainly open to improvements, and those will benefit all translations. Note that going to another markup implies you'll have to basically redo all that work from scratch and handle fixes (devil is in the details)
>
> I have no idea how much of a pain it is to use LaTeX for japanese. Do you input UTF-8, or one of the JIS encodings ? Do you have to write TeX hieroglyphs to express many things ?
>
>> >  Dr. Yoshiki Ohshima points that if we adopt another markup language
>> >  than laTeX, the appearance of final output will be different from ones
>> >  of other laTeX based projects, and that we should confirm if it is
>> >  acceptable to you, multi-l10n team.
> Appearance does not really matter that much. Actually the current typography could be simplified. IMHO what's really important is correct references, indexing... as well as being able to follow what's being done on the english version so that the translations are up-to-date.
>
> --
> Damien Pollet
> type less, do more [ | ]http://people.untyped.org/damien.pollet
>
>
>
>
> _______________________________________________
> Sbe-discussion mailing list
> Sbe-discussion at iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/sbe-discussion/attachments/20110610/2a8606eb/attachment.html>

From damien.pollet at inria.fr  Fri Jun 10 15:54:12 2011
From: damien.pollet at inria.fr (Damien Pollet)
Date: Fri, 10 Jun 2011 15:54:12 +0200
Subject: [sbe-discussion] Re: How should we markup Japanese version of PBE?
In-Reply-To: <4DF22060.5020709@gmail.com>
References: <4DF20001.8040705@gmail.com>
	<09A87D47-87D9-4ACE-AD98-D4C287C56F33@inria.fr>
	<4DF22060.5020709@gmail.com>
Message-ID: <0CAAD35E-6415-4BF3-A04E-25D59F7FED99@inria.fr>

On Jun 10, 2011, at 15:47, Hiroki Horiuchi wrote:

> First of all, I must apologize to you and to our team member also.
> I chose a word "hate" but it is too strong and must be wrong.

No worry, it's perfectly normal to hate LaTeX, I do too :)

The thing is, even if LaTeX has its inconvenients and tends to make its users crazy over time, it's still the most powerful tool I know for writing technical books.

--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet



From stephane.ducasse at free.fr  Fri Jun 10 16:04:42 2011
From: stephane.ducasse at free.fr (stephane ducasse)
Date: Fri, 10 Jun 2011 16:04:42 +0200
Subject: [sbe-discussion] Re: How should we markup Japanese version of PBE?
In-Reply-To: <4DF20001.8040705@gmail.com>
References: <4DF20001.8040705@gmail.com>
Message-ID: <1A1724F9-34C4-4465-AA33-006D413E8E20@free.fr>

Hi guys

I'm really happy to see our book translated. Now use what make you efficient even if I would prefer to have it in latex
so that we can rebuild everything if needed.

Stef

On Jun 10, 2011, at 1:29 PM, Hiroki Horiuchi wrote:

> Hello.
> 
> PBE-ja project has just begun. But there is a controversy: How should we
> markup it?
> 
> There is a strong opinion that markup language itself does not matter,
> just contents matter. From this opinion, Someone concludes that it is
> possible to separate marking-up from translation. Actually, some people
> likely hate marking-up. Another conclusion is that alternative markup
> language like Sphinx can/should be used.
> 
> Personally, I think the best way is that each translator does laTeX
> him/herself. But it does not seem to be a popular opinion.
> 
> Dr. Yoshiki Ohshima points that if we adopt another markup language
> than laTeX, the appearance of final output will be different from ones
> of other laTeX based projects, and that we should confirm if it is
> acceptable to you, multi-l10n team.
> 
> May I have your opinion?
> 
> Regards,
> 
> Hiroki Horiuchi
> 
> _______________________________________________
> Sbe-discussion mailing list
> Sbe-discussion at iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion
> 



From x19290 at gmail.com  Sat Jun 11 15:44:21 2011
From: x19290 at gmail.com (Hiroki Horiuchi)
Date: Sat, 11 Jun 2011 22:44:21 +0900
Subject: [sbe-discussion] Re: How should we markup Japanese version of PBE?
In-Reply-To: <4DF22060.5020709@gmail.com>
References: <4DF20001.8040705@gmail.com>
	<09A87D47-87D9-4ACE-AD98-D4C287C56F33@inria.fr>
	<4DF22060.5020709@gmail.com>
Message-ID: <4DF37135.1070401@gmail.com>

Hello.

This is a very short message because I am a bad English speaker.

Thank you for all your advices.
All of your advices are forwarded to our mailing-list.

/Fortunately, our leader now is considering about our LaTeXing./
There is no objection to the idea of LaTeXing by translator so far.
Nine of nineteen members are saying its OK.

Regards,

Hiroki Horiuchi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/sbe-discussion/attachments/20110611/a1f9b8e1/attachment.html>

From stephane.ducasse at free.fr  Sat Jun 11 17:03:52 2011
From: stephane.ducasse at free.fr (stephane ducasse)
Date: Sat, 11 Jun 2011 17:03:52 +0200
Subject: [sbe-discussion] Re: How should we markup Japanese version of PBE?
In-Reply-To: <4DF37135.1070401@gmail.com>
References: <4DF20001.8040705@gmail.com>
	<09A87D47-87D9-4ACE-AD98-D4C287C56F33@inria.fr>
	<4DF22060.5020709@gmail.com> <4DF37135.1070401@gmail.com>
Message-ID: <F8063A5C-75B0-4F96-AE3D-5EEC0813C42F@free.fr>


On Jun 11, 2011, at 3:44 PM, Hiroki Horiuchi wrote:

> Hello.
> 
> This is a very short message because I am a bad English speaker.

me too :)
My french is really better than my ugly english :)

> 
> Thank you for all your advices.
> All of your advices are forwarded to our mailing-list.
> 
> Fortunately, our leader now is considering about our LaTeXing.
> There is no objection to the idea of LaTeXing by translator so far.
> Nine of nineteen members are saying its OK.

Excellent!
This is wonderful to have Pharo-Jap :)

Stef

> Regards,
> 
> Hiroki Horiuchi
> 
> _______________________________________________
> Sbe-discussion mailing list
> Sbe-discussion at iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion


From yoshiki at vpri.org  Mon Jun 13 07:42:20 2011
From: yoshiki at vpri.org (Yoshiki Ohshima)
Date: Sun, 12 Jun 2011 22:42:20 -0700
Subject: [sbe-discussion] notes on "Understanding message syntax"
Message-ID: <m2ei2ygudg.wl%yoshiki@vpri.org>

  Hello,

  We started the Japanese translation project of PBE and I signed up
to look at "Messages.tex".  The following is a little note I took
while translating.  (As you can see, the original text is in "...",
and my comments are led by '->'.).

  To my taste, it seems to repeat itself a lot... but probably this is
from the experience of teaching it to students, so it is okay.  Also,
I'd separate the syntactical concepts and behavirol concepts a bit
more clearly.

  But in any case, thank you for writing such a textbook!

-- Yoshiki

----------------------------------------------------------------------------------
"Moreover, you cannot change the arity of a method"

  -> should avoid 'method', and stick with "message"?


"Unary messages are always sent first, then binary messages and finally keyword ones"

  -> To me, this statement is somewhat confusing as it feels like it
    is talking about some concurrency (as it leaves the idea of
    returning values out), or statements separated by periods.  Could
    it be better to stick with "evaluation" and "precedence" or
    "priority"?


"To help you identify the receiver of a message, we will underline it for you."

  -> It'd be nice if the "underlines" are (only) in the figures but
      not other places such as examples.

-> It is disturbing to see that the concepts in the syntax and the
   behavior at runtime is mixed up.  For example, it reads: "A
   receiver can be the first element of a message, such as \ct{100} in
   the message send".  To me "first element" is a syntactical concept.
   But then it goes "a receiver can also be the result of other
   messages".  To me "result" is something at runtime.


"They follow the syntactic template: \ct{receiver messageName}"

  -> "receiver" can be an expression, but "messageName" is a word, so
     it could be in different font.  (It could be called something
     else to signify that it is a word.)


"a sequence of one or more characters from the set: \ct{+}, \ct{-},
\ct{*}, \ct{/}, \ct{&}, \ct{=}, \ct{>}, \ct{|}, \ct{<}, \ct{~}, and
\ct{@}."

  -> Even within the ASCII range, Pharo actually allows ",", "\", "%",
     and "?" (and possibly some other non-printable ones).  The latter
     three may not be common but "," should be included.


"Color r: 1 g: 0 b: 0       --> Color red  "creates a new color""

  -> "Color red" does not craete a new color, but returns an existing
     one.  (Whether it creates a new one or returns exsiting one is an
     implementation detail.  So it'd be better to leave it open.)


"Keyword based messages"

  ->  Perhaps "Keyword-based messages", but I'd not suddenly introduce
      a new terminology, when it is called keyword messages elsewhere.


"Messages in \ind{parentheses} are sent prior to any kind ofmessages. "

  -> Yes...  and the result value is obtained before anything else
      happens.  So, sticking with the idea of "evaluation" may be
      easier to understand.


"Then we bind the argument \ct{aClass} to the concrete value \ct{Boolean}."

  -> Perhaps "... to the actual value" or "actual argument"?


"\mbox{\ct{isAbstract}}"

  -> \mbox is not needed?


"First the message between parentheses is sent: it contains two binary
messages \ct{65 at 325} and \ct{134 at 100} that are sent first and return
points"

  -> Even though it is explained right after this subsection, it
     certainly opens and leaves the question about the order of
     evaluation at this moment.


"To get the correct result, ..."
"...which produces the correct behaviour."

  -> In the expression "20 + (2 * 5)" or "20 + 2 * 5", there is
     nothing tells us that the latter is desired or "correct".  The
     numbers should use the readers' intuition, such as "7 * 3 + 365
     * 4" or something like that, to say that there is indeed an
     "expected" result.


"\important{In \st, arithmetic operators such as + and * do not have
different priority. \ct{+} and \ct{*} are just binary messages,
therefore \ct{*} does not have priority over \ct{+}. Use parentheses
to obtain the desired result.}"

  -> Here and a few other places, + and * are not enclosed in \ct{}.


"\section{Hints for identifying keyword messages}"

  -> The section name is about 'keyword messages", but it certainly
      involves other kinds of messages.


"\on{Sounds terribly complicated.}"

  -> ... I might have to agree ^^;


"If you have problems with these precedence rules, you may start
simply by putting parentheses whenever you want to distinguish two
messages having the same precedence."

  -> I cannot help but feeling that there is so much assumptions
      behind this hint.  To say the least, people should put
      parentheses to messages that have different precedence.


"So in \lct{(\emph{expression})}, the \lct{\emph{expression}} will
\emph{always} be evaluated exactly once."

  -> Yes, but "always" means "when execution reaches here".


"both the receiver and the argument of a \ct{whileTrue:} message require the use of square brackets..."

  -> Hmm, but they can certainly be variables, at least.
      (Regrettably, it is not general enough so you cannot use a
      message send that returns a block.)


"Note that the period is a \subind{statement}{separator} and not a
terminator. Therefore a final period is optional."

  -> If it is a separator, it would imply that the final period is an
      error.  Some elaboration may be good.


"Note that the object receiving the cascaded messages can itself be
the result of a message send. In fact ..."

  -> Somewhat hard to understand.


"A message is always sent to an object named the \emph{receiver} which
may be the result of other message sends."

  -> It reads like a receiver has to be named receiver.  Probably
      "called" is better?

From stephane.ducasse at free.fr  Mon Jun 13 18:12:34 2011
From: stephane.ducasse at free.fr (stephane ducasse)
Date: Mon, 13 Jun 2011 18:12:34 +0200
Subject: [sbe-discussion] Re: notes on "Understanding message syntax"
In-Reply-To: <m2ei2ygudg.wl%yoshiki@vpri.org>
References: <m2ei2ygudg.wl%yoshiki@vpri.org>
Message-ID: <7D0566A1-7BEE-439B-B37A-2354427A5ADD@free.fr>


On Jun 13, 2011, at 7:42 AM, Yoshiki Ohshima wrote:

>  Hello,
> 
>  We started the Japanese translation project of PBE and I signed up
> to look at "Messages.tex".  The following is a little note I took
> while translating.  (As you can see, the original text is in "...",
> and my comments are led by '->'.).
> 
>  To my taste, it seems to repeat itself a lot... but probably this is
> from the experience of teaching it to students, so it is okay.  Also,
> I'd separate the syntactical concepts and behavirol concepts a bit
> more clearly.
> 
>  But in any case, thank you for writing such a textbook!

Thanks for the feedback.
We should retrofit some part of it in the book. 

> 
> -- Yoshiki
> 
> ----------------------------------------------------------------------------------
> "Moreover, you cannot change the arity of a method"
> 
>  -> should avoid 'method', and stick with "message"?


yes  (even if we pay really attention method = what is executed and message the name).

> 
> "Unary messages are always sent first, then binary messages and finally keyword ones"
> 
>  -> To me, this statement is somewhat confusing as it feels like it
>    is talking about some concurrency (as it leaves the idea of
>    returning values out), or statements separated by periods.  Could
>    it be better to stick with "evaluation" and "precedence" or
>    "priority"?


With priority why you would not get the concurrency feeling?

> "To help you identify the receiver of a message, we will underline it for you."
> 
>  -> It'd be nice if the "underlines" are (only) in the figures but
>      not other places such as examples.

	why ? this is just to explain after we do not do it anymore. 

> 
> -> It is disturbing to see that the concepts in the syntax and the
>   behavior at runtime is mixed up.  For example, it reads: "A
>   receiver can be the first element of a message, such as \ct{100} in
>   the message send".  To me "first element" is a syntactical concept.
>   But then it goes "a receiver can also be the result of other
>   messages".  To me "result" is something at runtime.

why should we be only syntactic when talking about messages?
What is important is that people understand what you can do with them. 


> "They follow the syntactic template: \ct{receiver messageName}"
> 
>  -> "receiver" can be an expression, but "messageName" is a word, so
>     it could be in different font.  (It could be called something
>     else to signify that it is a word.)
> 
yes


> 
> "a sequence of one or more characters from the set: \ct{+}, \ct{-},
> \ct{*}, \ct{/}, \ct{&}, \ct{=}, \ct{>}, \ct{|}, \ct{<}, \ct{~}, and
> \ct{@}."
> 
>  -> Even within the ASCII range, Pharo actually allows ",", "\", "%",
>     and "?" (and possibly some other non-printable ones).  The latter
>     three may not be common but "," should be included.

yes we should add that.

> 
> 
> "Color r: 1 g: 0 b: 0       --> Color red  "creates a new color""
> 
>  -> "Color red" does not craete a new color, but returns an existing
>     one.  (Whether it creates a new one or returns exsiting one is an
>     implementation detail.  So it'd be better to leave it open.)


from a user perspective Color red creates a new color as well as Color r: 1 g: 0 b: 0 


> 
> 
> "Keyword based messages"
> 
>  ->  Perhaps "Keyword-based messages", but I'd not suddenly introduce
>      a new terminology, when it is called keyword messages elsewhere.
> 
> 
> "Messages in \ind{parentheses} are sent prior to any kind ofmessages. "
> 
>  -> Yes...  and the result value is obtained before anything else
>      happens.  So, sticking with the idea of "evaluation" may be
>      easier to understand.


the problem is that we avoid evaluation because people think that evaluation is for slow interpreted
languages while execution for real language like C++.


> "Then we bind the argument \ct{aClass} to the concrete value \ct{Boolean}."
> 
>  -> Perhaps "... to the actual value" or "actual argument"?

Why not

> 
> "\mbox{\ct{isAbstract}}"
> 
>  -> \mbox is not needed?
> 
> 
> "First the message between parentheses is sent: it contains two binary
> messages \ct{65 at 325} and \ct{134 at 100} that are sent first and return
> points"
> 
>  -> Even though it is explained right after this subsection, it
>     certainly opens and leaves the question about the order of
>     evaluation at this moment.

Indeed
> 
> "To get the correct result, ..."
> "...which produces the correct behaviour."
> 
>  -> In the expression "20 + (2 * 5)" or "20 + 2 * 5", there is
>     nothing tells us that the latter is desired or "correct".  The
>     numbers should use the readers' intuition, such as "7 * 3 + 365
>     * 4" or something like that, to say that there is indeed an
>     "expected" result.
> 
> 
> "\important{In \st, arithmetic operators such as + and * do not have
> different priority. \ct{+} and \ct{*} are just binary messages,
> therefore \ct{*} does not have priority over \ct{+}. Use parentheses
> to obtain the desired result.}"
> 
>  -> Here and a few other places, + and * are not enclosed in \ct{}.
> 
we should fix that

> 
> "\section{Hints for identifying keyword messages}"
> 
>  -> The section name is about 'keyword messages", but it certainly
>      involves other kinds of messages.
> 
> 
> "\on{Sounds terribly complicated.}"
> 
>  -> ... I might have to agree ^^;


Yes but this is true :)
This is just that nobody ever realize it but [ ] creates a scope that terminates message keywords identification


> 
> 
> "If you have problems with these precedence rules, you may start
> simply by putting parentheses whenever you want to distinguish two
> messages having the same precedence."
> 
>  -> I cannot help but feeling that there is so much assumptions
>      behind this hint.  To say the least, people should put
>      parentheses to messages that have different precedence.

this is what you do in math when you do not know and when you understand you start removing them. 
> 
> 
> "So in \lct{(\emph{expression})}, the \lct{\emph{expression}} will
> \emph{always} be evaluated exactly once."
> 
>  -> Yes, but "always" means "when execution reaches here".
> 
> 
> "both the receiver and the argument of a \ct{whileTrue:} message require the use of square brackets..."
> 
>  -> Hmm, but they can certainly be variables, at least.
>      (Regrettably, it is not general enough so you cannot use a
>      message send that returns a block.)

Indeed, the smalltalk haskish way.
> 
> 
> "Note that the period is a \subind{statement}{separator} and not a
> terminator. Therefore a final period is optional."
> 
>  -> If it is a separator, it would imply that the final period is an
>      error.  Some elaboration may be good.
> 
> 
> "Note that the object receiving the cascaded messages can itself be
> the result of a message send. In fact ..."
> 
>  -> Somewhat hard to understand.
> 
> 
> "A message is always sent to an object named the \emph{receiver} which
> may be the result of other message sends."
> 
>  -> It reads like a receiver has to be named receiver.  Probably
>      "called" is better?
> _______________________________________________
> Sbe-discussion mailing list
> Sbe-discussion at iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion
> 



From yoshiki at vpri.org  Mon Jun 13 19:00:13 2011
From: yoshiki at vpri.org (Yoshiki Ohshima)
Date: Mon, 13 Jun 2011 10:00:13 -0700
Subject: [sbe-discussion] Re: notes on "Understanding message syntax"
In-Reply-To: <7D0566A1-7BEE-439B-B37A-2354427A5ADD@free.fr>
References: <m2ei2ygudg.wl%yoshiki@vpri.org>
	<7D0566A1-7BEE-439B-B37A-2354427A5ADD@free.fr>
Message-ID: <m2boy1hdk2.wl%yoshiki@vpri.org>

At Mon, 13 Jun 2011 18:12:34 +0200,
stephane ducasse wrote:
> 
> 
> On Jun 13, 2011, at 7:42 AM, Yoshiki Ohshima wrote:
> 
> >  Hello,
> > 
> >  We started the Japanese translation project of PBE and I signed up
> > to look at "Messages.tex".  The following is a little note I took
> > while translating.  (As you can see, the original text is in "...",
> > and my comments are led by '->'.).
> > 
> >  To my taste, it seems to repeat itself a lot... but probably this is
> > from the experience of teaching it to students, so it is okay.  Also,
> > I'd separate the syntactical concepts and behavirol concepts a bit
> > more clearly.
> > 
> >  But in any case, thank you for writing such a textbook!
> 
> Thanks for the feedback.
> We should retrofit some part of it in the book. 

  Thank you.  One thing that would help many translators while the
original version is kept updated is to make the original in gettext
(possibly by using po4a)

> > "Unary messages are always sent first, then binary messages and finally keyword ones"
> > 
> >  -> To me, this statement is somewhat confusing as it feels like it
> >    is talking about some concurrency (as it leaves the idea of
> >    returning values out), or statements separated by periods.  Could
> >    it be better to stick with "evaluation" and "precedence" or
> >    "priority"?
> 
> 
> With priority why you would not get the concurrency feeling?

  Provided that it discusses returning values from send, then that
means the next send is after the return and priority sorts out the
order.

> > "To help you identify the receiver of a message, we will underline it for you."
> > 
> >  -> It'd be nice if the "underlines" are (only) in the figures but
> >      not other places such as examples.
> 
> 	why ? this is just to explain after we do not do it anymore. 

  Hmm?  You do it on pages 66, 68 (figure 4.4 and 4.5), 69, (but not
some of the ones on 70 and 71).

> > -> It is disturbing to see that the concepts in the syntax and the
> >   behavior at runtime is mixed up.  For example, it reads: "A
> >   receiver can be the first element of a message, such as \ct{100} in
> >   the message send".  To me "first element" is a syntactical concept.
> >   But then it goes "a receiver can also be the result of other
> >   messages".  To me "result" is something at runtime.
> 
> why should we be only syntactic when talking about messages?
> What is important is that people understand what you can do with them. 

  Sure.  But to understand what is an "element" in "the first
element", the reader would need some mental switch to look at it.

> > "Color r: 1 g: 0 b: 0       --> Color red  "creates a new color""
> > 
> >  -> "Color red" does not craete a new color, but returns an existing
> >     one.  (Whether it creates a new one or returns exsiting one is an
> >     implementation detail.  So it'd be better to leave it open.)
> 
> 
> from a user perspective Color red creates a new color as well as Color r: 1 g: 0 b: 0 

  My point is that from a user's perspective, all it matters is that
he gets an instance of Color as the return value but he should not
care if it is "created" or not.

> > "Messages in \ind{parentheses} are sent prior to any kind ofmessages. "
> > 
> >  -> Yes...  and the result value is obtained before anything else
> >      happens.  So, sticking with the idea of "evaluation" may be
> >      easier to understand.
> 
> 
> the problem is that we avoid evaluation because people think that evaluation is for slow interpreted
> languages while execution for real language like C++.

  Hmm, ok.

> > "Then we bind the argument \ct{aClass} to the concrete value \ct{Boolean}."
> > 
> >  -> Perhaps "... to the actual value" or "actual argument"?
> 
> Why not

  "Concrete" has a connotation with "abstract class vs. concreate
class" (especially because this part is dealing with abstract methods)
concept, and also a more common terminology of parameter passing is
"formal vs. actual".

-- Yoshiki

From stephane.ducasse at free.fr  Wed Jun 15 08:47:24 2011
From: stephane.ducasse at free.fr (stephane ducasse)
Date: Wed, 15 Jun 2011 08:47:24 +0200
Subject: [sbe-discussion] Re: notes on "Understanding message syntax"
In-Reply-To: <m2boy1hdk2.wl%yoshiki@vpri.org>
References: <m2ei2ygudg.wl%yoshiki@vpri.org>
	<7D0566A1-7BEE-439B-B37A-2354427A5ADD@free.fr>
	<m2boy1hdk2.wl%yoshiki@vpri.org>
Message-ID: <D1098083-4F22-47AF-B0E7-47341B7E24D5@free.fr>

>>> 
>> 
>> Thanks for the feedback.
>> We should retrofit some part of it in the book. 
> 
>  Thank you.  One thing that would help many translators while the
> original version is kept updated is to make the original in gettext
> (possibly by using po4a)

our problem is that we cannot rewrite everything and I'm focusing on the second book. 

> 
>>> "Unary messages are always sent first, then binary messages and finally keyword ones"
>>> 
>>> -> To me, this statement is somewhat confusing as it feels like it
>>>   is talking about some concurrency (as it leaves the idea of
>>>   returning values out), or statements separated by periods.  Could
>>>   it be better to stick with "evaluation" and "precedence" or
>>>   "priority"?
>> 
>> 
>> With priority why you would not get the concurrency feeling?
> 
>  Provided that it discusses returning values from send, then that
> means the next send is after the return and priority sorts out the
> order.
> 
>>> "To help you identify the receiver of a message, we will underline it for you."
>>> 
>>> -> It'd be nice if the "underlines" are (only) in the figures but
>>>     not other places such as examples.
>> 
>> 	why ? this is just to explain after we do not do it anymore. 
> 
>  Hmm?  You do it on pages 66, 68 (figure 4.4 and 4.5), 69, (but not
> some of the ones on 70 and 71).

ok we will check that

> 
>>> -> It is disturbing to see that the concepts in the syntax and the
>>>  behavior at runtime is mixed up.  For example, it reads: "A
>>>  receiver can be the first element of a message, such as \ct{100} in
>>>  the message send".  To me "first element" is a syntactical concept.
>>>  But then it goes "a receiver can also be the result of other
>>>  messages".  To me "result" is something at runtime.
>> 
>> why should we be only syntactic when talking about messages?
>> What is important is that people understand what you can do with them. 
> 
>  Sure.  But to understand what is an "element" in "the first
> element", the reader would need some mental switch to look at it.
> 
>>> "Color r: 1 g: 0 b: 0       --> Color red  "creates a new color""
>>> 
>>> -> "Color red" does not craete a new color, but returns an existing
>>>    one.  (Whether it creates a new one or returns exsiting one is an
>>>    implementation detail.  So it'd be better to leave it open.)
>> 
>> 
>> from a user perspective Color red creates a new color as well as Color r: 1 g: 0 b: 0 
> 
>  My point is that from a user's perspective, all it matters is that
> he gets an instance of Color as the return value but he should not
> care if it is "created" or not.

ah ok of course.

> 
>>> "Messages in \ind{parentheses} are sent prior to any kind ofmessages. "
>>> 
>>> -> Yes...  and the result value is obtained before anything else
>>>     happens.  So, sticking with the idea of "evaluation" may be
>>>     easier to understand.
>> 
>> 
>> the problem is that we avoid evaluation because people think that evaluation is for slow interpreted
>> languages while execution for real language like C++.
> 
>  Hmm, ok.
> 
>>> "Then we bind the argument \ct{aClass} to the concrete value \ct{Boolean}."
>>> 
>>> -> Perhaps "... to the actual value" or "actual argument"?
>> 
>> Why not
> 
>  "Concrete" has a connotation with "abstract class vs. concreate
> class" (especially because this part is dealing with abstract methods)
> concept, and also a more common terminology of parameter passing is
> "formal vs. actual".

ok

> 
> -- Yoshiki
> _______________________________________________
> Sbe-discussion mailing list
> Sbe-discussion at iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion
> 



From marianopeck at gmail.com  Thu Jun 16 12:51:13 2011
From: marianopeck at gmail.com (Mariano Martinez Peck)
Date: Thu, 16 Jun 2011 12:51:13 +0200
Subject: [sbe-discussion] Re: [Pharo-users] PBE.image
In-Reply-To: <4DF9DB98.6030501@arcor.de>
References: <4DF9DB98.6030501@arcor.de>
Message-ID: <BANLkTimYcjmVh2L+fcVp4x8Ru-p0FfOJUA@mail.gmail.com>

Hi. There was a change in the last years in Pharo and we have a new VM
called CogVM which is the default since Pharo 1.1.1. So, Pharo 1.2.1 one
click may probbaly be using a CogVM.
CogVM cannot open "old" Pharo images. I guess, that PBE.image is an "old"
Pharo image, say 1.0, and hence, cannot be opened with a CogVM.

So....you should try a non-cog VM. For example, you can try the same you did
but with
http://gforge.inria.fr/frs/download.php/27303/Pharo-1.1-OneClick.zip

Or...ask if someone can recreate a new PBE.image cog compatible.

Good luck.

Mariano

On Thu, Jun 16, 2011 at 12:31 PM, bb <bblochl at arcor.de> wrote:

> I run Pharo on Linux and tried to start Pharo with the PBE.image, that
> is offered as an add on to the Pharo by example book. I copied PBE.image
> and PBE.change to Pharo-1.2.1-OneClick.app/Contents/Resources/ (where
> pharo.image and pharo.change reside as well) and changed the last line
> in pharo.sh from
> "$ROOT/Contents/Resources/pharo.image"
> to
> "$ROOT/Contents/Resources/PBE.image"
>
> When I start the shell-script nothing happens. What is wrong with my
> experiment. With pharo.image pharo starts properly.
>
> I tried to change the setting in pharo.ini from pharo.image to PBE.image
> as well. No success!
>
> What is wrong?
>
> Regards B Blochl
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/sbe-discussion/attachments/20110616/cdf57cd3/attachment.html>

From marcus.denker at inria.fr  Thu Jun 16 14:54:54 2011
From: marcus.denker at inria.fr (Marcus Denker)
Date: Thu, 16 Jun 2011 14:54:54 +0200
Subject: [sbe-discussion] Re: [Pharo-users] PBE.image
In-Reply-To: <1234825866.1399520.1308221487165.JavaMail.root@zmbs4.inria.fr>
References: <4DF9DB98.6030501@arcor.de>
	<1234825866.1399520.1308221487165.JavaMail.root@zmbs4.inria.fr>
Message-ID: <3F4F475D-9B39-4144-8BCB-A062A9F2858D@inria.fr>


On Jun 16, 2011, at 12:51 PM, Mariano Martinez Peck wrote:

> Hi. There was a change in the last years in Pharo and we have a new VM called CogVM which is the default since Pharo 1.1.1. So, Pharo 1.2.1 one click may probbaly be using a CogVM.
> CogVM cannot open "old" Pharo images. I guess, that PBE.image is an "old" Pharo image, say 1.0, and hence, cannot be opened with a CogVM.
> 
> So....you should try a non-cog VM. For example, you can try the same you did but with http://gforge.inria.fr/frs/download.php/27303/Pharo-1.1-OneClick.zip
> 
> Or...ask if someone can recreate a new PBE.image cog compatible. 
> 

This is not possible as it is based on 1.0, and 1.0 is not compatible to Cog. 

	Marcus

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.



From marianopeck at gmail.com  Thu Jun 16 21:28:17 2011
From: marianopeck at gmail.com (Mariano Martinez Peck)
Date: Thu, 16 Jun 2011 21:28:17 +0200
Subject: [sbe-discussion] Re: [Pharo-users] PBE.image
In-Reply-To: <BANLkTimUOsfQtT+f6yzvz3B-h=8o201=OA@mail.gmail.com>
References: <4DF9DB98.6030501@arcor.de>
	<1234825866.1399520.1308221487165.JavaMail.root@zmbs4.inria.fr>
	<3F4F475D-9B39-4144-8BCB-A062A9F2858D@inria.fr>
	<BANLkTimUOsfQtT+f6yzvz3B-h=8o201=OA@mail.gmail.com>
Message-ID: <BANLkTinej=4ch-sCRVKUT5k8qKpMArWQBA@mail.gmail.com>

On Thu, Jun 16, 2011 at 9:16 PM, Robert Shiplett <grshiplett at gmail.com>wrote:

> Marcus
>
> But there will be a 1.3  PBE  image ?
>
>
No. There is man power to do that. All screenshots for example of PBE were
done with the system browse O2 which doesn't even work now in Pharo 1.3. In
addition, examples, and code of the book have changed/removed in Pharo 1.3.
So, no.
It is easy. If you want PBE image, then use the correct VM for it.

Now, PBE 2 book is around the corner. Hopefully this book is based on new
versions of Pharo and PBE2 image will be probably be cog compatible.

Cheers



> Robert
>
>
> On 16 June 2011 09:54, Marcus Denker <marcus.denker at inria.fr> wrote:
> >
> > On Jun 16, 2011, at 12:51 PM, Mariano Martinez Peck wrote:
> >
> >> Hi. There was a change in the last years in Pharo and we have a new VM
> called CogVM which is the default since Pharo 1.1.1. So, Pharo 1.2.1 one
> click may probbaly be using a CogVM.
> >> CogVM cannot open "old" Pharo images. I guess, that PBE.image is an
> "old" Pharo image, say 1.0, and hence, cannot be opened with a CogVM.
> >>
> >> So....you should try a non-cog VM. For example, you can try the same you
> did but with
> http://gforge.inria.fr/frs/download.php/27303/Pharo-1.1-OneClick.zip
> >>
> >> Or...ask if someone can recreate a new PBE.image cog compatible.
> >>
> >
> > This is not possible as it is based on 1.0, and 1.0 is not compatible to
> Cog.
> >
> >        Marcus
> >
> > --
> > Marcus Denker  -- http://www.marcusdenker.de
> > INRIA Lille -- Nord Europe. Team RMoD.
> >
> >
> >
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/sbe-discussion/attachments/20110616/bb75b5a0/attachment.html>

From ume at softumeya.com  Tue Jun 21 04:11:43 2011
From: ume at softumeya.com (Masashi Umezawa)
Date: Tue, 21 Jun 2011 11:11:43 +0900
Subject: [sbe-discussion] Seaside chapter
Message-ID: <BANLkTin=AC2xbQEo1dX-ZTko2tNq0GxwCw@mail.gmail.com>

Hello,

The Japanese translation project of PBE is just under way, and I'm now
translating chapter 12 - Seaside by Example.
What I'm concerned about is that the content is based on Seaside 2.8.
Will it be updated to 3.0-based one in PBE 2? If so, is it better to
wait for the updated version?

Best regards,
-- 
[:masashi | ^umezawa]

From stephane.ducasse at free.fr  Tue Jun 21 15:00:09 2011
From: stephane.ducasse at free.fr (stephane ducasse)
Date: Tue, 21 Jun 2011 15:00:09 +0200
Subject: [sbe-discussion] Re: Seaside chapter
In-Reply-To: <BANLkTin=AC2xbQEo1dX-ZTko2tNq0GxwCw@mail.gmail.com>
References: <BANLkTin=AC2xbQEo1dX-ZTko2tNq0GxwCw@mail.gmail.com>
Message-ID: <5EE22833-DC67-476B-8622-1600561B7A51@free.fr>

Hello 

Yes it would be better.
We could change the seaside chapter in english too or may be that you do it directly since it may be simpler
while doing the japanese translation.

Stef

On Jun 21, 2011, at 4:11 AM, Masashi Umezawa wrote:

> Hello,
> 
> The Japanese translation project of PBE is just under way, and I'm now
> translating chapter 12 - Seaside by Example.
> What I'm concerned about is that the content is based on Seaside 2.8.
> Will it be updated to 3.0-based one in PBE 2? If so, is it better to
> wait for the updated version?
> 
> Best regards,
> -- 
> [:masashi | ^umezawa]
> _______________________________________________
> Sbe-discussion mailing list
> Sbe-discussion at iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion
> 



From grshiplett at gmail.com  Thu Jun 23 23:51:08 2011
From: grshiplett at gmail.com (Robert Shiplett)
Date: Thu, 23 Jun 2011 18:51:08 -0300
Subject: [sbe-discussion] Is this list also for PBE discuss
Message-ID: <BANLkTik3WTBu+GCq22SvFKCivg3PPqFTCg@mail.gmail.com>

Is this list also for discussing PBE2 ?

I have starting committing English edits to my grshiplett fork on the
github for SquareBrackets

Robert

From oscar at iam.unibe.ch  Fri Jun 24 09:30:59 2011
From: oscar at iam.unibe.ch (Oscar Nierstrasz)
Date: Fri, 24 Jun 2011 09:30:59 +0200
Subject: [sbe-discussion] Re: Is this list also for PBE discuss
In-Reply-To: <BANLkTik3WTBu+GCq22SvFKCivg3PPqFTCg@mail.gmail.com>
References: <BANLkTik3WTBu+GCq22SvFKCivg3PPqFTCg@mail.gmail.com>
Message-ID: <CEDED9B4-7B41-460D-B25D-90D8CFF13D4D@iam.unibe.ch>


Hi Robert,

Yes, this is the right list.

Cheers,
- on

On Jun 23, 2011, at 23:51 , Robert Shiplett wrote:

> Is this list also for discussing PBE2 ?
> 
> I have starting committing English edits to my grshiplett fork on the
> github for SquareBrackets
> 
> Robert
> _______________________________________________
> Sbe-discussion mailing list
> Sbe-discussion at iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion


From grshiplett at gmail.com  Fri Jun 24 13:45:57 2011
From: grshiplett at gmail.com (Robert Shiplett)
Date: Fri, 24 Jun 2011 08:45:57 -0300
Subject: [sbe-discussion] Re: Is this list also for PBE discuss
In-Reply-To: <CEDED9B4-7B41-460D-B25D-90D8CFF13D4D@iam.unibe.ch>
References: <BANLkTik3WTBu+GCq22SvFKCivg3PPqFTCg@mail.gmail.com>
	<CEDED9B4-7B41-460D-B25D-90D8CFF13D4D@iam.unibe.ch>
Message-ID: <BANLkTikZA2mc=TFg2DG0xKfjXDsp4-0qTQ@mail.gmail.com>

Attn: Stef, Dale, Mariano:

Please pull into github master the latest metacello.tex from my
grshiplett fork before making additions to Metcello chapter.

Feedback would be most appreciated.

Thanks / merci

Robert Shiplett
Fredericton, NB, Canada [ Atlantic tz  UCT-0300 ]
grshiplett AT G[oogle]mail dot com


On 24 June 2011 04:30, Oscar Nierstrasz <oscar at iam.unibe.ch> wrote:
>
> Hi Robert,
>
> Yes, this is the right list.
>
> Cheers,
> - on
>
> On Jun 23, 2011, at 23:51 , Robert Shiplett wrote:
>
>> Is this list also for discussing PBE2 ?
>>
>> I have starting committing English edits to my grshiplett fork on the
>> github for SquareBrackets
>>
>> Robert
>> _______________________________________________
>> Sbe-discussion mailing list
>> Sbe-discussion at iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion
>
> _______________________________________________
> Sbe-discussion mailing list
> Sbe-discussion at iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion
>

From stephane.ducasse at free.fr  Wed Jun 29 10:02:36 2011
From: stephane.ducasse at free.fr (stephane ducasse)
Date: Wed, 29 Jun 2011 10:02:36 +0200
Subject: [sbe-discussion] Re: Is this list also for PBE discuss
In-Reply-To: <BANLkTikZA2mc=TFg2DG0xKfjXDsp4-0qTQ@mail.gmail.com>
References: <BANLkTik3WTBu+GCq22SvFKCivg3PPqFTCg@mail.gmail.com>
	<CEDED9B4-7B41-460D-B25D-90D8CFF13D4D@iam.unibe.ch>
	<BANLkTikZA2mc=TFg2DG0xKfjXDsp4-0qTQ@mail.gmail.com>
Message-ID: <7CA2BBBF-1079-4553-8986-B2BD0C2DB1A0@free.fr>

Thanks I will try to understand how I can do that


On Jun 24, 2011, at 1:45 PM, Robert Shiplett wrote:

> Attn: Stef, Dale, Mariano:
> 
> Please pull into github master the latest metacello.tex from my
> grshiplett fork before making additions to Metcello chapter.
> 
> Feedback would be most appreciated.
> 
> Thanks / merci
> 
> Robert Shiplett
> Fredericton, NB, Canada [ Atlantic tz  UCT-0300 ]
> grshiplett AT G[oogle]mail dot com
> 
> 
> On 24 June 2011 04:30, Oscar Nierstrasz <oscar at iam.unibe.ch> wrote:
>> 
>> Hi Robert,
>> 
>> Yes, this is the right list.
>> 
>> Cheers,
>> - on
>> 
>> On Jun 23, 2011, at 23:51 , Robert Shiplett wrote:
>> 
>>> Is this list also for discussing PBE2 ?
>>> 
>>> I have starting committing English edits to my grshiplett fork on the
>>> github for SquareBrackets
>>> 
>>> Robert
>>> _______________________________________________
>>> Sbe-discussion mailing list
>>> Sbe-discussion at iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion
>> 
>> _______________________________________________
>> Sbe-discussion mailing list
>> Sbe-discussion at iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion
>> 
> _______________________________________________
> Sbe-discussion mailing list
> Sbe-discussion at iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion
> 


From damien.cassou at gmail.com  Wed Jun 29 11:02:17 2011
From: damien.cassou at gmail.com (Damien Cassou)
Date: Wed, 29 Jun 2011 11:02:17 +0200
Subject: [sbe-discussion] Re: Is this list also for PBE discuss
In-Reply-To: <BANLkTikZA2mc=TFg2DG0xKfjXDsp4-0qTQ@mail.gmail.com>
References: <BANLkTik3WTBu+GCq22SvFKCivg3PPqFTCg@mail.gmail.com>
	<CEDED9B4-7B41-460D-B25D-90D8CFF13D4D@iam.unibe.ch>
	<BANLkTikZA2mc=TFg2DG0xKfjXDsp4-0qTQ@mail.gmail.com>
Message-ID: <BANLkTim9hpWs1664HD+VNwJTm2cWg99rq8Tuuk6XTjCbVPCu-w@mail.gmail.com>

Dear Robert,

On Fri, Jun 24, 2011 at 1:45 PM, Robert Shiplett <grshiplett at gmail.com> wrote:
> Please pull into github master the latest metacello.tex from my
> grshiplett fork before making additions to Metcello chapter.
>
> Feedback would be most appreciated.

please pull the latest changes from the main repository and issue a
pull request by clicking on the top right button of the github window
'Pull Request'. Please contact me if you can't find your way inside
github or git.

Bye

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry

From stephane.ducasse at free.fr  Wed Jun 29 16:38:34 2011
From: stephane.ducasse at free.fr (stephane ducasse)
Date: Wed, 29 Jun 2011 16:38:34 +0200
Subject: [sbe-discussion] Re: Is this list also for PBE discuss
In-Reply-To: <BANLkTim9hpWs1664HD+VNwJTm2cWg99rq8Tuuk6XTjCbVPCu-w@mail.gmail.com>
References: <BANLkTik3WTBu+GCq22SvFKCivg3PPqFTCg@mail.gmail.com>
	<CEDED9B4-7B41-460D-B25D-90D8CFF13D4D@iam.unibe.ch>
	<BANLkTikZA2mc=TFg2DG0xKfjXDsp4-0qTQ@mail.gmail.com>
	<BANLkTim9hpWs1664HD+VNwJTm2cWg99rq8Tuuk6XTjCbVPCu-w@mail.gmail.com>
Message-ID: <F449D3E8-FEFA-4E41-947F-1CF43371D280@free.fr>

tx
I will try

On Jun 29, 2011, at 11:02 AM, Damien Cassou wrote:

> Dear Robert,
> 
> On Fri, Jun 24, 2011 at 1:45 PM, Robert Shiplett <grshiplett at gmail.com> wrote:
>> Please pull into github master the latest metacello.tex from my
>> grshiplett fork before making additions to Metcello chapter.
>> 
>> Feedback would be most appreciated.
> 
> please pull the latest changes from the main repository and issue a
> pull request by clicking on the top right button of the github window
> 'Pull Request'. Please contact me if you can't find your way inside
> github or git.
> 
> Bye
> 
> -- 
> Damien Cassou
> http://damiencassou.seasidehosting.st
> 
> "Lambdas are relegated to relative obscurity until Java makes them
> popular by not having them." James Iry
> _______________________________________________
> Sbe-discussion mailing list
> Sbe-discussion at iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion
>