gambas-devel — gambas development mailing-list

Re: [Gambas-devel] Gambas 3.10 - gb.web.feed

[Tobias B. <ta...@gm...>]

On Fri, 28 Jul 2017, Benoît Minisini via Gambas-devel wrote:
> > Yes, the timezone is mandatory there.
> > 
> > So, how about this: I make a class called RssDate where I store a UTC-based
> > timestamp (aka Date) and a timezone string. As I mentioned before, I think
> > the timezone string is necessary to let the user specify what timezone the
> > date will be printed in.
> > 
> > When an RFC822 date is read, I want to have its timezone string and the
> > timestamp of that date converted to UTC. When an RFC822 date is written,
> > I take the UTC timestamp and convert it to the string representation in
> > the timezone that the user wants to print the date in.
> > 
> > If that sounds reasonable, I can get to work now.
> > 
> > Regards,
> > Tobi
> > 
> 
> Why do you need the timezone part of the RFC822 date as a string? Why not
> just using Gambas Date and the Date.ToRFC822() / Date.FromRFC822()
> functions?
> 

When I read an RSS document into Rss objects, I want to retain the timezone
strings used in the original document. If I don't know the timezone string,
I would have to reset all timezones to UTC. The dates will be correct but
the timezone in the string representation of the date will have changed
(and the timezone may carry a meaning). It would be nice just to be able
to replicate a document that I have just read into gb.web.feed, too.

The attached script demonstrates two other problems:

  Print Date.ToRFC822(Date.FromRFC822("28 Jul 2017 08:00:00 GMT"), "GMT")
  >>Fri, 28 Jul 2017 4:0:0 GMT

First of all, the time components are not Format$(..., "00")'d, so they
print single digits where the RFC requires 2 digits. And second, shouldn't
reading a GMT date and putting it into GMT again result in the same string
that we started with? The 4 hour different is likely because I'm in +0200.

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk

Re: [Gambas-devel] Fwd: Re: Gambas to Git(Lab)

[Christof T. <ch...@de...>]

Hi,

Am 28.07.2017 um 16:35 schrieb Adrien Prokopowicz:
> If we need to make a patch release for bugfixes in the meantime, we can  
> just use the master
> branch to get back to the latest stable, and then make the fixes from  
> there.
> If the fix is already done on the development version, we can cherry-pick  
> it from the dev
> branch, and otherwise we can just make the fix on master (or on a  
> temporary branch), and
> then merge master back into the development branch.
> 
> This is also the workflow I use at work so maybe I'm too used to it and  
> don't see
> the downsides, but to me it seems to cover all of the use-cases.
> 
> [0] https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows

Assume, Gambas gets bigger and more important and somewhere in the
future there exists a Gambas 3.20 in old distributions like Debian and
Gambas 4.05 in current Ubuntu, each of these versions is "stable".

Assume also there is a security breach introduced in Gambas 3.10 ;-)

How would you insert a hotfix which would lead to stable 3.21 and stable
4.06 in your model? IMO ... that would be impossible.


Alles Gute

Christof Thalhofer

-- 
Dies ist keine Signatur

Re: [Gambas-devel] Fwd: Re: Gambas to Git(Lab)

[Adrien P. <adr...@gm...>]

Le Sun, 23 Jul 2017 12:02:30 +0200, Christof Thalhofer  
<ch...@de...> a écrit:

> Here is a good explanation of common git workflows:
> https://www.atlassian.com/git/tutorials/comparing-workflows
>
> Why do you want to develop in different versions at the same time, to
> fix bugs? Look at "Maintenance Branches" and "Hotfix", maybe that is,
> what you wanted to do?
>
> I am unsure what sort of development workflow would be the best for  
> Gambas.
>
> If I look at a big projekt for example that put its codebase to Git –
> OTRS – they did it so:
>
> https://github.com/OTRS/otrs
>
> Look there at the branches and tags. They seem to have ongoing
> development in master with branches for the "big" releases. Tags are
> used to point to subreleases.
>
>
> Alles Gute
>
> Christof Thalhofer

I took a bit of time to think about it, and I think the best workflow for
developing Gambas would be the one that's described in the Git  
documentation[0] :

- The master branch is the stable branch : it only contains the latest  
stable
   release of gambas. (with tags to keep the previous releases).
- A dev branch, for the development version. (the equivalent of the  
current trunk).
- Various branches for work-in-progress features that are not ready at all  
(like gb.term.form)

This way, we keep a workflow similar to the current one for bug fixes &  
minor changes
(we just commit to the dev branch).
For bigger changes and experimental components we create a new branch from  
the dev branch,
work on it, and then merge it back in the development branch when it's  
ready.
And when we want to release a new Gambas version, we just merge the  
development branch
in master, and create a tag to mark the new release.

If we need to make a patch release for bugfixes in the meantime, we can  
just use the master
branch to get back to the latest stable, and then make the fixes from  
there.
If the fix is already done on the development version, we can cherry-pick  
it from the dev
branch, and otherwise we can just make the fix on master (or on a  
temporary branch), and
then merge master back into the development branch.

This is also the workflow I use at work so maybe I'm too used to it and  
don't see
the downsides, but to me it seems to cover all of the use-cases.

[0] https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows

-- 
Adrien Prokopowicz

Re: [Gambas-devel] Gambas 3.10 - gb.web.feed

[Benoît M. <ga...@us...>]

Le 28/07/2017 à 15:57, Tobias Boege a écrit :
>>
>> Sorry, I forgot to deal with your requests.
>>
> 
> And I came back from vacation just recently. As I see 3.10 wasn't released
> yet. I'll try to push the changes today, if we can agree on them.
> 

I go to vacation tommorow, and come back next week. So I think I will 
make the release in a week, so that you have more time.

>> You should internally use Gambas date, not strings, as Gambas date are
>> internally UTC timestamps.
>>
>> The trick is that when you make a date with Date(Year, Month, ...), the
>> values you are giving are in the local timezone.
>>
>> This is the reason why I'm substracting Frac(Date(Now)): it moves the date
>> to the UTC time zone (as Now is in local time, the fractional part of
>> Date(Now) converted to float is the timezone).
>>
>> Frac(Date(Now)) and -(System.TimeZone / 86400) are the same value (up to the
>> 4th decimal digit, because of different precision).
>>
>> And isn't the timezone mandatory in a RFC822 date?
> 
> Yes, the timezone is mandatory there.
> 
> So, how about this: I make a class called RssDate where I store a UTC-based
> timestamp (aka Date) and a timezone string. As I mentioned before, I think
> the timezone string is necessary to let the user specify what timezone the
> date will be printed in.
> 
> When an RFC822 date is read, I want to have its timezone string and the
> timestamp of that date converted to UTC. When an RFC822 date is written,
> I take the UTC timestamp and convert it to the string representation in
> the timezone that the user wants to print the date in.
> 
> If that sounds reasonable, I can get to work now.
> 
> Regards,
> Tobi
> 

Why do you need the timezone part of the RFC822 date as a string? Why 
not just using Gambas Date and the Date.ToRFC822() / Date.FromRFC822() 
functions?

-- 
Benoît Minisini

Re: [Gambas-devel] Gambas 3.10 - gb.web.feed

[Tobias B. <ta...@gm...>]

On Sat, 22 Jul 2017, Benoît Minisini wrote:
> Le 01/07/2017 à 21:46, Tobias Boege a écrit :
> > On Sat, 01 Jul 2017, Beno�t Minisini via Gambas-devel wrote:
> > > I will have some time next week, and I want to release Gambas 3.10.
> > 
> > Hi Benoit,
> > 
> > Gambas 3.10 would include the new gb.web.feed, right? I have some local
> > changes pending which better be committed before the component is first
> > included in a stable version.
> > 
> > As I mentioned earlier, I want Date values in RSS to be accompanied by
> > an RFC822 timezone string, because I want to give the user a way to
> > specify the timezone string when they create RSS documents (e.g. an RSS
> > feed of a local newspaper in Germany should not have the timezone of
> > the US-located server machine where the feed is put together, but the
> > German timezone relevant to the article).
> > 
> > I need the following:
> > 
> >    1. A way to get the timezone string out of the RFC822 parser in gb.util.
> >    2. Two functions which convert between RFC822 timezone string and
> >       a numeric representation (number of seconds from UTC?) I believe
> >       those functions are already in gb.util, but Private.
> >    3. An RFC822 timezone string for the local system timezone, as a
> >       reasonable default when the user gives no timezone.
> >    4. Functions which convert a (date, timezone) pair, which is to be
> >       understood as "<date> is in/relative to <timezone>" to another
> >       timezone.
> > 
> > I think if 1. and 2. are there, I can implement 3. and 4. by myself.
> > Having 4. would give me a clean conscience, as I intend to store the
> > timezone inside the component just as an RFC822 timezone string and
> > let the user handle calculations with timezones if they need it.
> > Point 4. then gives the user the needed primitives.
> > 
> > Please also look at [1] where I listed some doubts I have about the
> > current RFC822 functions in gb.util.
> > 
> > Regards,
> > Tobi
> > 
> > [1] https://sourceforge.net/p/gambas/mailman/message/35810371/
> > 
> 
> Sorry, I forgot to deal with your requests.
> 

And I came back from vacation just recently. As I see 3.10 wasn't released
yet. I'll try to push the changes today, if we can agree on them.

> You should internally use Gambas date, not strings, as Gambas date are
> internally UTC timestamps.
> 
> The trick is that when you make a date with Date(Year, Month, ...), the
> values you are giving are in the local timezone.
> 
> This is the reason why I'm substracting Frac(Date(Now)): it moves the date
> to the UTC time zone (as Now is in local time, the fractional part of
> Date(Now) converted to float is the timezone).
> 
> Frac(Date(Now)) and -(System.TimeZone / 86400) are the same value (up to the
> 4th decimal digit, because of different precision).
> 
> And isn't the timezone mandatory in a RFC822 date?

Yes, the timezone is mandatory there.

So, how about this: I make a class called RssDate where I store a UTC-based
timestamp (aka Date) and a timezone string. As I mentioned before, I think
the timezone string is necessary to let the user specify what timezone the
date will be printed in.

When an RFC822 date is read, I want to have its timezone string and the
timestamp of that date converted to UTC. When an RFC822 date is written,
I take the UTC timestamp and convert it to the string representation in
the timezone that the user wants to print the date in.

If that sounds reasonable, I can get to work now.

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk

[Gambas-devel] user gambas -> group gambas

[PICCORO M. L. <mck...@gm...>]

Benoit  i suggested change the user gambas to a group.. due this way can
handle common prospect over same group of developming..

for understand that, see some group examples as :
https://github.com/owncloud that have the projects and the people involved

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Re: [Gambas-devel] Gambas group taken in gitlab..

[PICCORO M. L. <mck...@gm...>]

benoit, you can inegrating the github, gitlab and SF groups/repositories,
like i do with venenux/elsistema in gitlab and github..

when something made a commit in the repo, gitlab make a autocommit to the
folk in github

there's ahother way, using git in your local, but its not automatic..
depends of user,and if users has too many things in mind.. something forget
to do that..

also has some hooks,

also trigger to twitter or mail on each commit, like venenux does with list

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

2017-07-23 11:29 GMT-04:30 Benoît Minisini <ga...@us...>:

> Le 23/07/2017 à 16:24, PICCORO McKAY Lenz a écrit :
>
>> and i see that https://gitlab.com/gambas was already taken.. to setup a
>> property group and integration collaboration..
>>
>> Lenz McKAY Gerardo (PICCORO)
>> http://qgqlochekone.blogspot.com
>>
>>
> It's me. :-)
>
> I created that user in prevision of the switch to git.
>
> --
> Benoît Minisini
>

Re: [Gambas-devel] Gambas group taken in gitlab..

[Benoît M. <ga...@us...>]

Le 23/07/2017 à 16:24, PICCORO McKAY Lenz a écrit :
> and i see that https://gitlab.com/gambas was already taken.. to setup a 
> property group and integration collaboration..
> 
> Lenz McKAY Gerardo (PICCORO)
> http://qgqlochekone.blogspot.com
> 

It's me. :-)

I created that user in prevision of the switch to git.

-- 
Benoît Minisini

Re: [Gambas-devel] Gambas group taken in gitlab..

[PICCORO M. L. <mck...@gm...>]

and i see that https://gitlab.com/gambas was already taken.. to setup a
property group and integration collaboration..

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

2017-07-23 9:47 GMT-04:30 PICCORO McKAY Lenz <mck...@gm...>:

> git have REAL branchs and tas.. SVN do just copy's, also SVN its
> centraliced a problem in team collaborations , due the fusion of resulting
> jobs comes in many deadlocks at the developer side.. of course at the
> server central side are very easy to mantain.. but we must see the horizont
>
> i'm not avocate of "up to date things" but in this way are really need..
> also the SF interface are so slower when i goin to the cybercafe.. due i'm
> not have internet access at my home..
>
> so in many ways the SVN (and for me that the most important part) can work
> offline.. SVN need connection alive to mark commits... its very tedious for
> me use SVN due i not have internet connection.. so  that the mayor
> problem.. the very centralised behavior that git does are more flexible!
>
>
>> Date: Sun, 23 Jul 2017 01:33:09 +0200
>> From: Beno?t Minisini <ga...@us...>
>> The problem I encountered when moving from subversion to git in my job
>> is that git does not really have tags and branches that behave the same
>> way. I.e. being actual independent trees.
>>
>> A recently added feature named "working tree" in git seems to help to do
>> the same thing: developing on different versions at the same time.
>>
>> Or maybe I didn't understand how to use git for that?
>>
>> Regards,
>>
>> --
>> Beno?t Minisini
>>
>> --
>> Beno?t Minisini
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Sun, 23 Jul 2017 04:01:04 +0200
>> From: "Adrien Prokopowicz" <adr...@gm...>
>> To: "mailing list for gambas developers"
>>         <gam...@li...>
>> Subject: Re: [Gambas-devel] Gambas to Git(Lab)
>> Message-ID: <op.y3s3v2cwdlsaci@localhost>
>> Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
>>
>> Le Sun, 23 Jul 2017 01:33:09 +0200, Beno?t Minisini via Gambas-devel
>> <gam...@li...> a ?crit:
>> >
>> > The problem I encountered when moving from subversion to git in my job
>> > is that git does not really have tags and branches that behave the same
>> > way. I.e. being actual independent trees.
>> >
>> > A recently added feature named "working tree" in git seems to help to do
>> > the same thing: developing on different versions at the same time.
>> >
>> > Or maybe I didn't understand how to use git for that?
>> >
>> > Regards,
>> >
>>
>> You can work on different versions/branches at the same time. It's just
>> that branches
>> in Git are waay different from SVN branches. :)
>>
>> In SVN, both branches and tags do not really exist : they are just
>> separate
>> directories, and creating a new branch/tag essentially means copying the
>> entire
>> directory over, from /trunk to /branches/3.10 for example.
>> (SVN actually uses some Copy-on-Write mechanisms under the hood, such as
>> hard-links,
>> but from the user point of view it is just a regular copy).
>>
>> In Git however, branches are more of a diverged history : they share the
>> same history
>> up to the point where you create the branch, but then the commits you make
>> in each
>> branch are completely separate.
>> For example, you create a new 3.10 branch from the master (main) branch.
>> The commits
>> you add to the 3.10 branch will not be applied to the master branch, and
>> if you switch
>> back to master, you are in the same state you were before creating the
>> branch, and from
>> there you can add some commits to master (which will not affect 3.10).
>>
>> You can check out the Git documentation about branches here [0]. It has
>> diagrams
>> and all the commands needed to work with branches. But if you (in the
>> broad sense, not
>> just Beno?t) have questions, you can just ask me. :)
>>
>> What I really like about workflows based on Git branches, is that they
>> make it really
>> easy to start working on new (and unfinished) features without submitting
>> them
>> to the main branch. You simply create a new branch and start working in
>> it, allowing
>> everyone to see your work and provide feedback, without having to include
>> it in the
>> next release.
>> And when your work is ready, you just merge it back into the main branch.
>> :)
>>
>> A recent example of this would be the gb.term.form component : Fabien
>> started working
>> on it at the time of Gambas 3.9, but just said it is not ready for 3.10.
>> If the unfinished
>> component is in its own branch, then you can just release what is on the
>> main branch
>> without worrying. (This kind of workflow is also explained in the Git
>> documentation,
>> see here[1]).
>>
>> What makes this workflow even more awesome is the fact than anybody (on
>> GitLab/GitHub)
>> can fork the Gambas repository (i.e. copy the repository into a new one
>> they own),
>> make changes in their repository, and then ask to merge the changes
>> through a
>> Merge Request[2] (GitHub calls these Pull Requests). You can then review
>> their
>> changes, approve them (or not), and merge them.
>> This is great for allowing one-time contributors to participate without
>> having to
>> give them full permissions on the repository (and it's much better than
>> sending
>> a patch for review). :)
>>
>> (? and here I made a hundred-page-long message again. Sorry about that,
>> but Git
>> is exciting !)
>>
>> Regards,
>>
>> [0]
>> https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
>> [1] https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows
>> [2] https://docs.gitlab.com/ee/user/project/merge_requests/index.html
>>
>> --
>> Adrien Prokopowicz
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Sun, 23 Jul 2017 12:02:30 +0200
>> From: Christof Thalhofer <ch...@de...>
>> To: mailing list for gambas developers
>>         <gam...@li...>
>> Subject: Re: [Gambas-devel] Fwd: Re: Gambas to Git(Lab)
>> Message-ID: <dc6...@de...>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Am 23.07.2017 um 01:33 schrieb Beno?t Minisini via Gambas-devel:
>>
>> > The problem I encountered when moving from subversion to git in my job
>> > is that git does not really have tags and branches that behave the same
>> > way. I.e. being actual independent trees.
>> >
>> > A recently added feature named "working tree" in git seems to help to do
>> > the same thing: developing on different versions at the same time.
>>
>> I did not use that feature, as I only switch between different branches
>> in my code (maybe one for each release). But it seems to have advantages
>> if you have very big repositories (where switching between branches
>> costs too much time):
>>
>> https://stackoverflow.com/questions/31935776/what-would-i-
>> use-git-worktree-for
>>
>> > Or maybe I didn't understand how to use git for that?
>>
>> Here is a good explanation of common git workflows:
>> https://www.atlassian.com/git/tutorials/comparing-workflows
>>
>> Why do you want to develop in different versions at the same time, to
>> fix bugs? Look at "Maintenance Branches" and "Hotfix", maybe that is,
>> what you wanted to do?
>>
>> I am unsure what sort of development workflow would be the best for
>> Gambas.
>>
>> If I look at a big projekt for example that put its codebase to Git ?
>> OTRS ? they did it so:
>>
>> https://github.com/OTRS/otrs
>>
>> Look there at the branches and tags. They seem to have ongoing
>> development in master with branches for the "big" releases. Tags are
>> used to point to subreleases.
>>
>>
>> Alles Gute
>>
>> Christof Thalhofer
>>
>> --
>> Dies ist keine Signatur
>>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: signature.asc
>> Type: application/pgp-signature
>> Size: 819 bytes
>> Desc: OpenPGP digital signature
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Sun, 23 Jul 2017 12:03:45 +0200
>> From: Christof Thalhofer <ch...@de...>
>> To: mailing list for gambas developers
>>         <gam...@li...>
>> Subject: Re: [Gambas-devel] Gambas to Git(Lab)
>> Message-ID: <5db...@de...>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Am 23.07.2017 um 04:01 schrieb Adrien Prokopowicz:
>>
>> > but Git
>> > is exciting !)
>>
>> Yes! Full Ack!
>> :-)
>>
>> I love to work with Git. It makes the horizont so much wider.
>>
>>
>> Alles Gute
>>
>> Christof Thalhofer
>>
>> --
>> Dies ist keine Signatur
>>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: signature.asc
>> Type: application/pgp-signature
>> Size: 819 bytes
>> Desc: OpenPGP digital signature
>>
>> ------------------------------
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> Gambas-devel mailing list
>> Gam...@li...
>> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>>
>>
>> ------------------------------
>>
>> End of Gambas-devel Digest, Vol 112, Issue 3
>> ********************************************
>>
>
>

Re: [Gambas-devel] Gambas to Git(Lab)

[PICCORO M. L. <mck...@gm...>]

git have REAL branchs and tas.. SVN do just copy's, also SVN its
centraliced a problem in team collaborations , due the fusion of resulting
jobs comes in many deadlocks at the developer side.. of course at the
server central side are very easy to mantain.. but we must see the horizont

i'm not avocate of "up to date things" but in this way are really need..
also the SF interface are so slower when i goin to the cybercafe.. due i'm
not have internet access at my home..

so in many ways the SVN (and for me that the most important part) can work
offline.. SVN need connection alive to mark commits... its very tedious for
me use SVN due i not have internet connection.. so  that the mayor
problem.. the very centralised behavior that git does are more flexible!


> Date: Sun, 23 Jul 2017 01:33:09 +0200
> From: Beno?t Minisini <ga...@us...>
> The problem I encountered when moving from subversion to git in my job
> is that git does not really have tags and branches that behave the same
> way. I.e. being actual independent trees.
>
> A recently added feature named "working tree" in git seems to help to do
> the same thing: developing on different versions at the same time.
>
> Or maybe I didn't understand how to use git for that?
>
> Regards,
>
> --
> Beno?t Minisini
>
> --
> Beno?t Minisini
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 23 Jul 2017 04:01:04 +0200
> From: "Adrien Prokopowicz" <adr...@gm...>
> To: "mailing list for gambas developers"
>         <gam...@li...>
> Subject: Re: [Gambas-devel] Gambas to Git(Lab)
> Message-ID: <op.y3s3v2cwdlsaci@localhost>
> Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
>
> Le Sun, 23 Jul 2017 01:33:09 +0200, Beno?t Minisini via Gambas-devel
> <gam...@li...> a ?crit:
> >
> > The problem I encountered when moving from subversion to git in my job
> > is that git does not really have tags and branches that behave the same
> > way. I.e. being actual independent trees.
> >
> > A recently added feature named "working tree" in git seems to help to do
> > the same thing: developing on different versions at the same time.
> >
> > Or maybe I didn't understand how to use git for that?
> >
> > Regards,
> >
>
> You can work on different versions/branches at the same time. It's just
> that branches
> in Git are waay different from SVN branches. :)
>
> In SVN, both branches and tags do not really exist : they are just separate
> directories, and creating a new branch/tag essentially means copying the
> entire
> directory over, from /trunk to /branches/3.10 for example.
> (SVN actually uses some Copy-on-Write mechanisms under the hood, such as
> hard-links,
> but from the user point of view it is just a regular copy).
>
> In Git however, branches are more of a diverged history : they share the
> same history
> up to the point where you create the branch, but then the commits you make
> in each
> branch are completely separate.
> For example, you create a new 3.10 branch from the master (main) branch.
> The commits
> you add to the 3.10 branch will not be applied to the master branch, and
> if you switch
> back to master, you are in the same state you were before creating the
> branch, and from
> there you can add some commits to master (which will not affect 3.10).
>
> You can check out the Git documentation about branches here [0]. It has
> diagrams
> and all the commands needed to work with branches. But if you (in the
> broad sense, not
> just Beno?t) have questions, you can just ask me. :)
>
> What I really like about workflows based on Git branches, is that they
> make it really
> easy to start working on new (and unfinished) features without submitting
> them
> to the main branch. You simply create a new branch and start working in
> it, allowing
> everyone to see your work and provide feedback, without having to include
> it in the
> next release.
> And when your work is ready, you just merge it back into the main branch.
> :)
>
> A recent example of this would be the gb.term.form component : Fabien
> started working
> on it at the time of Gambas 3.9, but just said it is not ready for 3.10.
> If the unfinished
> component is in its own branch, then you can just release what is on the
> main branch
> without worrying. (This kind of workflow is also explained in the Git
> documentation,
> see here[1]).
>
> What makes this workflow even more awesome is the fact than anybody (on
> GitLab/GitHub)
> can fork the Gambas repository (i.e. copy the repository into a new one
> they own),
> make changes in their repository, and then ask to merge the changes
> through a
> Merge Request[2] (GitHub calls these Pull Requests). You can then review
> their
> changes, approve them (or not), and merge them.
> This is great for allowing one-time contributors to participate without
> having to
> give them full permissions on the repository (and it's much better than
> sending
> a patch for review). :)
>
> (? and here I made a hundred-page-long message again. Sorry about that,
> but Git
> is exciting !)
>
> Regards,
>
> [0]
> https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
> [1] https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows
> [2] https://docs.gitlab.com/ee/user/project/merge_requests/index.html
>
> --
> Adrien Prokopowicz
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 23 Jul 2017 12:02:30 +0200
> From: Christof Thalhofer <ch...@de...>
> To: mailing list for gambas developers
>         <gam...@li...>
> Subject: Re: [Gambas-devel] Fwd: Re: Gambas to Git(Lab)
> Message-ID: <dc6...@de...>
> Content-Type: text/plain; charset="utf-8"
>
> Am 23.07.2017 um 01:33 schrieb Beno?t Minisini via Gambas-devel:
>
> > The problem I encountered when moving from subversion to git in my job
> > is that git does not really have tags and branches that behave the same
> > way. I.e. being actual independent trees.
> >
> > A recently added feature named "working tree" in git seems to help to do
> > the same thing: developing on different versions at the same time.
>
> I did not use that feature, as I only switch between different branches
> in my code (maybe one for each release). But it seems to have advantages
> if you have very big repositories (where switching between branches
> costs too much time):
>
> https://stackoverflow.com/questions/31935776/what-would-
> i-use-git-worktree-for
>
> > Or maybe I didn't understand how to use git for that?
>
> Here is a good explanation of common git workflows:
> https://www.atlassian.com/git/tutorials/comparing-workflows
>
> Why do you want to develop in different versions at the same time, to
> fix bugs? Look at "Maintenance Branches" and "Hotfix", maybe that is,
> what you wanted to do?
>
> I am unsure what sort of development workflow would be the best for Gambas.
>
> If I look at a big projekt for example that put its codebase to Git ?
> OTRS ? they did it so:
>
> https://github.com/OTRS/otrs
>
> Look there at the branches and tags. They seem to have ongoing
> development in master with branches for the "big" releases. Tags are
> used to point to subreleases.
>
>
> Alles Gute
>
> Christof Thalhofer
>
> --
> Dies ist keine Signatur
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 819 bytes
> Desc: OpenPGP digital signature
>
> ------------------------------
>
> Message: 5
> Date: Sun, 23 Jul 2017 12:03:45 +0200
> From: Christof Thalhofer <ch...@de...>
> To: mailing list for gambas developers
>         <gam...@li...>
> Subject: Re: [Gambas-devel] Gambas to Git(Lab)
> Message-ID: <5db...@de...>
> Content-Type: text/plain; charset="utf-8"
>
> Am 23.07.2017 um 04:01 schrieb Adrien Prokopowicz:
>
> > but Git
> > is exciting !)
>
> Yes! Full Ack!
> :-)
>
> I love to work with Git. It makes the horizont so much wider.
>
>
> Alles Gute
>
> Christof Thalhofer
>
> --
> Dies ist keine Signatur
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 819 bytes
> Desc: OpenPGP digital signature
>
> ------------------------------
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Gambas-devel mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>
>
> ------------------------------
>
> End of Gambas-devel Digest, Vol 112, Issue 3
> ********************************************
>

Re: [Gambas-devel] Gambas to Git(Lab)

[Christof T. <ch...@de...>]

Am 23.07.2017 um 04:01 schrieb Adrien Prokopowicz:

> but Git
> is exciting !)

Yes! Full Ack!
:-)

I love to work with Git. It makes the horizont so much wider.


Alles Gute

Christof Thalhofer

-- 
Dies ist keine Signatur

Re: [Gambas-devel] Fwd: Re: Gambas to Git(Lab)

[Christof T. <ch...@de...>]

Am 23.07.2017 um 01:33 schrieb Benoît Minisini via Gambas-devel:

> The problem I encountered when moving from subversion to git in my job 
> is that git does not really have tags and branches that behave the same 
> way. I.e. being actual independent trees.
> 
> A recently added feature named "working tree" in git seems to help to do 
> the same thing: developing on different versions at the same time.

I did not use that feature, as I only switch between different branches
in my code (maybe one for each release). But it seems to have advantages
if you have very big repositories (where switching between branches
costs too much time):

https://stackoverflow.com/questions/31935776/what-would-i-use-git-worktree-for

> Or maybe I didn't understand how to use git for that?

Here is a good explanation of common git workflows:
https://www.atlassian.com/git/tutorials/comparing-workflows

Why do you want to develop in different versions at the same time, to
fix bugs? Look at "Maintenance Branches" and "Hotfix", maybe that is,
what you wanted to do?

I am unsure what sort of development workflow would be the best for Gambas.

If I look at a big projekt for example that put its codebase to Git –
OTRS – they did it so:

https://github.com/OTRS/otrs

Look there at the branches and tags. They seem to have ongoing
development in master with branches for the "big" releases. Tags are
used to point to subreleases.


Alles Gute

Christof Thalhofer

-- 
Dies ist keine Signatur

Re: [Gambas-devel] Gambas to Git(Lab)

[Adrien P. <adr...@gm...>]

Le Sun, 23 Jul 2017 01:33:09 +0200, Benoît Minisini via Gambas-devel  
<gam...@li...> a écrit:
>
> The problem I encountered when moving from subversion to git in my job  
> is that git does not really have tags and branches that behave the same  
> way. I.e. being actual independent trees.
>
> A recently added feature named "working tree" in git seems to help to do  
> the same thing: developing on different versions at the same time.
>
> Or maybe I didn't understand how to use git for that?
>
> Regards,
>

You can work on different versions/branches at the same time. It's just  
that branches
in Git are waay different from SVN branches. :)

In SVN, both branches and tags do not really exist : they are just separate
directories, and creating a new branch/tag essentially means copying the  
entire
directory over, from /trunk to /branches/3.10 for example.
(SVN actually uses some Copy-on-Write mechanisms under the hood, such as  
hard-links,
but from the user point of view it is just a regular copy).

In Git however, branches are more of a diverged history : they share the  
same history
up to the point where you create the branch, but then the commits you make  
in each
branch are completely separate.
For example, you create a new 3.10 branch from the master (main) branch.  
The commits
you add to the 3.10 branch will not be applied to the master branch, and  
if you switch
back to master, you are in the same state you were before creating the  
branch, and from
there you can add some commits to master (which will not affect 3.10).

You can check out the Git documentation about branches here [0]. It has  
diagrams
and all the commands needed to work with branches. But if you (in the  
broad sense, not
just Benoît) have questions, you can just ask me. :)

What I really like about workflows based on Git branches, is that they  
make it really
easy to start working on new (and unfinished) features without submitting  
them
to the main branch. You simply create a new branch and start working in  
it, allowing
everyone to see your work and provide feedback, without having to include  
it in the
next release.
And when your work is ready, you just merge it back into the main branch.  
:)

A recent example of this would be the gb.term.form component : Fabien  
started working
on it at the time of Gambas 3.9, but just said it is not ready for 3.10.  
If the unfinished
component is in its own branch, then you can just release what is on the  
main branch
without worrying. (This kind of workflow is also explained in the Git  
documentation,
see here[1]).

What makes this workflow even more awesome is the fact than anybody (on  
GitLab/GitHub)
can fork the Gambas repository (i.e. copy the repository into a new one  
they own),
make changes in their repository, and then ask to merge the changes  
through a
Merge Request[2] (GitHub calls these Pull Requests). You can then review  
their
changes, approve them (or not), and merge them.
This is great for allowing one-time contributors to participate without  
having to
give them full permissions on the repository (and it's much better than  
sending
a patch for review). :)

(… and here I made a hundred-page-long message again. Sorry about that,  
but Git
is exciting !)

Regards,

[0]  
https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
[1] https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows
[2] https://docs.gitlab.com/ee/user/project/merge_requests/index.html

-- 
Adrien Prokopowicz

[Gambas-devel] Fwd: Re: Gambas to Git(Lab)

[Benoît M. <ga...@us...>]

Le 22/07/2017 à 20:35, Adrien Prokopowicz a écrit :
> Hello everyone,
> 
> In an effort to both switch the Gambas project versioning to Git, and to 
> move away
> from Sourceforge, I imported the whole repository to GitLab. You can see 
> it here :
> 
> https://gitlab.com/prokopyl/gambas
> 
>  From what I see, all history, commits, tags and branches have been 
> successfully
> imported, and authors have been correctly mapped from their Sourceforge 
> usernames to
> Git full names and emails (the SVN/Git mapping file is attached).
> 
> I know there has been some GitHub vs. GitLab debate on the mailing list 
> somewhere,
> but it didn't seem to have produced anything, so I just picked one.
> Since nothing I have done is GitLab-specific (it's just a plain Git 
> repository for now),
> we can easily use GitHub too.
> I personally picked GitLab simply because we can easily retrieve data 
> (issues, wiki and such)
> from a generated archive if we ever want to switch, and their integrated 
> CI solution
> seems less restricted than Travis (but I didn't go that far with it).
> 
> For now, all I did was cloning the entire SVN repo on the server that 
> hosts the
> playground (for its symmetric 100Mbit/s connection :) ), then using 
> git-svn to
> create a git repo from the clone, and then push it all to GitLab.
> 
> I'm currently trying to set up Continuous Integration to generate Ubuntu 
> packages, and
> maybe for more distributions later (RHEL/CentOS, Debian, ArchLinux, …).
> 
> I know we won't switch to Git right now, I'm at least waiting for 3.10 
> to be released
> so everything can calm down. :)
> However I would like your feedback : what do you think is needed to make 
> Gambas
> successfully switch to Git ? (Whichever host we end up choosing).
> 
> Regards,
> 

The problem I encountered when moving from subversion to git in my job 
is that git does not really have tags and branches that behave the same 
way. I.e. being actual independent trees.

A recently added feature named "working tree" in git seems to help to do 
the same thing: developing on different versions at the same time.

Or maybe I didn't understand how to use git for that?

Regards,

-- 
Benoît Minisini

-- 
Benoît Minisini

Re: [Gambas-devel] Gambas to Git(Lab)

[Adrien P. <adr...@gm...>]

Le Sat, 22 Jul 2017 21:19:54 +0200, Karl Reinl <kar...@fe...> a  
écrit:
>
> Salut Adrien,
>
> a short test shows me the Copy Links get a 404.
> But I do not know anything about GitXX
>
>

Hi Karl,

These links are just the messages for commits that Benoît wrote 9 years  
ago.
They apparently point to the old 2.0 repository on sourceforge, which does
not exist anymore. You can see the corresponding commit on sourceforge[0].

Since it is just an old message, I don't think you have to worry about
these broken links. :)

Regards,

[0] https://sourceforge.net/p/gambas/code/8167/log/?path=/gambas/trunk/NEWS
-- 
Adrien Prokopowicz

Re: [Gambas-devel] Gambas to Git(Lab)

[Karl R. <kar...@fe...>]

Am Samstag, den 22.07.2017, 20:35 +0200 schrieb Adrien Prokopowicz:
> Hello everyone,
> 
> In an effort to both switch the Gambas project versioning to Git, and to  
> move away
>  from Sourceforge, I imported the whole repository to GitLab. You can see  
> it here :
> 
> https://gitlab.com/prokopyl/gambas
> 
>  From what I see, all history, commits, tags and branches have been  
> successfully
> imported, and authors have been correctly mapped from their Sourceforge  
> usernames to
> Git full names and emails (the SVN/Git mapping file is attached).
> 
> I know there has been some GitHub vs. GitLab debate on the mailing list  
> somewhere,
> but it didn't seem to have produced anything, so I just picked one.
> Since nothing I have done is GitLab-specific (it's just a plain Git  
> repository for now),
> we can easily use GitHub too.
> I personally picked GitLab simply because we can easily retrieve data  
> (issues, wiki and such)
>  from a generated archive if we ever want to switch, and their integrated  
> CI solution
> seems less restricted than Travis (but I didn't go that far with it).
> 
> For now, all I did was cloning the entire SVN repo on the server that  
> hosts the
> playground (for its symmetric 100Mbit/s connection :) ), then using  
> git-svn to
> create a git repo from the clone, and then push it all to GitLab.
> 
> I'm currently trying to set up Continuous Integration to generate Ubuntu  
> packages, and
> maybe for more distributions later (RHEL/CentOS, Debian, ArchLinux, …).
> 
> I know we won't switch to Git right now, I'm at least waiting for 3.10 to  
> be released
> so everything can calm down. :)
> However I would like your feedback : what do you think is needed to make  
> Gambas
> successfully switch to Git ? (Whichever host we end up choosing).

Salut Adrien,

a short test shows me the Copy Links get a 404.
But I do not know anything about GitXX


-- 
Amicalement
Charlie

[Gambas-devel] Gambas to Git(Lab)

[Adrien P. <adr...@gm...>]

Hello everyone,

In an effort to both switch the Gambas project versioning to Git, and to  
move away
 from Sourceforge, I imported the whole repository to GitLab. You can see  
it here :

https://gitlab.com/prokopyl/gambas

 From what I see, all history, commits, tags and branches have been  
successfully
imported, and authors have been correctly mapped from their Sourceforge  
usernames to
Git full names and emails (the SVN/Git mapping file is attached).

I know there has been some GitHub vs. GitLab debate on the mailing list  
somewhere,
but it didn't seem to have produced anything, so I just picked one.
Since nothing I have done is GitLab-specific (it's just a plain Git  
repository for now),
we can easily use GitHub too.
I personally picked GitLab simply because we can easily retrieve data  
(issues, wiki and such)
 from a generated archive if we ever want to switch, and their integrated  
CI solution
seems less restricted than Travis (but I didn't go that far with it).

For now, all I did was cloning the entire SVN repo on the server that  
hosts the
playground (for its symmetric 100Mbit/s connection :) ), then using  
git-svn to
create a git repo from the clone, and then push it all to GitLab.

I'm currently trying to set up Continuous Integration to generate Ubuntu  
packages, and
maybe for more distributions later (RHEL/CentOS, Debian, ArchLinux, …).

I know we won't switch to Git right now, I'm at least waiting for 3.10 to  
be released
so everything can calm down. :)
However I would like your feedback : what do you think is needed to make  
Gambas
successfully switch to Git ? (Whichever host we end up choosing).

Regards,
-- 
Adrien Prokopowicz

Re: [Gambas-devel] Translation for gambas 3.9.2 Chinease Simplified

[Benoît M. <ga...@us...>]

Le 24/04/2017 à 06:58, Yizhou He a écrit :
> Hi,
> 
> Sorry if I post in wrong mail list. Lost all my contact in email after 
> finish graduate school. They take my mail box away. Please let me know 
> where I'm supposed to submit the updated translation file if I post in 
> wrong list.
> 
> 
> Thanks,
> 
> 
> 
> Yizhou He
> 

I have merged your translation in the upcoming 3.10 version.

Otherwise, you can ask me a write access to the subversion repository. 
Then you make and commit your translation directly from the IDE.

Regards,

-- 
Benoît Minisini

[Gambas-devel] Gambas 3.10 - gb.web.feed

[Tobias B. <ta...@gm...>]

On Sat, 01 Jul 2017, Beno�t Minisini via Gambas-devel wrote:
> I will have some time next week, and I want to release Gambas 3.10.

Hi Benoit,

Gambas 3.10 would include the new gb.web.feed, right? I have some local
changes pending which better be committed before the component is first
included in a stable version.

As I mentioned earlier, I want Date values in RSS to be accompanied by
an RFC822 timezone string, because I want to give the user a way to
specify the timezone string when they create RSS documents (e.g. an RSS
feed of a local newspaper in Germany should not have the timezone of
the US-located server machine where the feed is put together, but the
German timezone relevant to the article).

I need the following:

  1. A way to get the timezone string out of the RFC822 parser in gb.util.
  2. Two functions which convert between RFC822 timezone string and
     a numeric representation (number of seconds from UTC?) I believe
     those functions are already in gb.util, but Private.
  3. An RFC822 timezone string for the local system timezone, as a
     reasonable default when the user gives no timezone.
  4. Functions which convert a (date, timezone) pair, which is to be
     understood as "<date> is in/relative to <timezone>" to another
     timezone.

I think if 1. and 2. are there, I can implement 3. and 4. by myself.
Having 4. would give me a clean conscience, as I intend to store the
timezone inside the component just as an RFC822 timezone string and
let the user handle calculations with timezones if they need it.
Point 4. then gives the user the needed primitives.

Please also look at [1] where I listed some doubts I have about the
current RFC822 functions in gb.util.

Regards,
Tobi

[1] https://sourceforge.net/p/gambas/mailman/message/35810371/

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk

Re: [Gambas-devel] Unit-Tests

[Benoît M. <ga...@us...>]

Le 01/07/2017 à 11:40, Christof Thalhofer a écrit :
> Hello Benoît,
> 
> I write you because I got no answer in the dev-ML. Is there any interest
> in integrating the UnitTest to the IDE on your side? Or do you have no
> time, currently?
> 
> If Yes (interest):
> 
> There is a new version on Github (had to do a small fix):
> https://github.com/Deganius/gb.deg.unittest
> 
> To see it work, just load the Project and hit F5.
> 
> But there is a major problem with it:
> 
> It should be able to inspect and test a project "from the outside" and I
> did not find a way to do that.
> 
> 
> Thank you and a nice weekend!
> 
> Christof Thalhofer
> 

I have answered you on the devel mailing-list, I just asked first if it 
was commented in english.

Then your component just have to be put in the subversion repository.

I will mainly check the interface of your component and the names of 
your symbol. I have read your documentation on github, and I'm not sure 
I like them! :-)

I will have some time next week, and I want to release Gambas 3.10. 
Maybe we can put your code in /trunk just after that?

Regards,

-- 
Benoît Minisini

Re: [Gambas-devel] Gambas Unit-Test

[Christof T. <ch...@de...>]

Am 27.06.2017 um 20:26 schrieb PICCORO McKAY Lenz:
> great and wonderfully, good job

Thanks :-)

> I would like to contribute to Gambass with this project: 
> https://github.com/Deganius/gb.deg.unittest 
> <https://github.com/Deganius/gb.deg.unittest>
> 
> Could this become an official component of future Gambas and if yes, 
> how?
> 
> It is runnning stable in all my projects, and does its job quite
> well. But I have to call its state "alpha" because it lacks
> integration into the IDE.
> 
> 
> like the java unit testing suite ... user create t4esting methods an 
> define expected results in the test suite.. run the test and see the 
> results.. very good..
> 
> maybe a console interface/version will be need due many targets are 
> packagin objetives... so must take in consideration a console
> versino that packaging tools can called

Yes. The component could be divided into two parts, one that does the
testing and outputs to console and a separated gui part.

One thing that is ugly: If it is used to test a library and the lib is
afterwords used by another project, in that project the
Unittest-component has also to be defined as component.

I did not find any way around that.


Alles Gute

Christof Thalhofer

-- 
Dies ist keine Signatur

Re: [Gambas-devel] Gambas Unit-Test

[PICCORO M. L. <mck...@gm...>]

great and wonderfully, good job

I would like to contribute to Gambass with this project:
> https://github.com/Deganius/gb.deg.unittest
>
> Could this become an official component of future Gambas and if yes, how?
>
> It is runnning stable in all my projects, and does its job quite well.
> But I have to call its state "alpha" because it lacks integration into
> the IDE.
>

like the java unit testing suite ...  user create t4esting methods an
define expected results in the test suite.. run the test and see the
results.. very good..

maybe a console interface/version will be need due many targets are
packagin objetives... so must take in consideration a console versino that
packaging tools can called

...and good stored in git, i can see easyle the changes across time without
problems of svn subdirectories conflicts..

Re: [Gambas-devel] Gambas Unit-Test

[Benoît M. <ga...@us...>]

Le 27/06/2017 à 11:58, Benoît Minisini a écrit :
> Le 27/06/2017 à 11:48, Christof Thalhofer a écrit :
>> Hello,
>>
>> I would like to contribute to Gambass with this project:
>> https://github.com/Deganius/gb.deg.unittest
>>
>> Could this become an official component of future Gambas and if yes, how?
>>
>> It is runnning stable in all my projects, and does its job quite well.
>> But I have to call its state "alpha" because it lacks integration into
>> the IDE.
>>
>>
>> Alles Gute
>>
>> Christof Thalhofer
>>
> 
> Do you have some documentation written somewhere?
> 
> Is it commented in english?
> 

OK I found it...

-- 
Benoît Minisini

Re: [Gambas-devel] Gambas Unit-Test

[Benoît M. <ga...@us...>]

Le 27/06/2017 à 11:48, Christof Thalhofer a écrit :
> Hello,
> 
> I would like to contribute to Gambass with this project:
> https://github.com/Deganius/gb.deg.unittest
> 
> Could this become an official component of future Gambas and if yes, how?
> 
> It is runnning stable in all my projects, and does its job quite well.
> But I have to call its state "alpha" because it lacks integration into
> the IDE.
> 
> 
> Alles Gute
> 
> Christof Thalhofer
> 

Do you have some documentation written somewhere?

Is it commented in english?

-- 
Benoît Minisini

[Gambas-devel] Gambas Unit-Test

[Christof T. <ch...@de...>]

Hello,

I would like to contribute to Gambass with this project:
https://github.com/Deganius/gb.deg.unittest

Could this become an official component of future Gambas and if yes, how?

It is runnning stable in all my projects, and does its job quite well.
But I have to call its state "alpha" because it lacks integration into
the IDE.


Alles Gute

Christof Thalhofer

-- 
[x] nail here for new monitor