gambas-devel Mailing List for Gambas (Page 3)
Brought to you by:
gambas
This list is closed, nobody may subscribe to it.
2003 |
Jan
(8) |
Feb
(17) |
Mar
(10) |
Apr
(19) |
May
(39) |
Jun
(82) |
Jul
(12) |
Aug
(21) |
Sep
(50) |
Oct
(21) |
Nov
(45) |
Dec
(42) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(83) |
Feb
(58) |
Mar
(18) |
Apr
(63) |
May
(33) |
Jun
(36) |
Jul
(42) |
Aug
(154) |
Sep
(90) |
Oct
(117) |
Nov
(120) |
Dec
(73) |
2005 |
Jan
(231) |
Feb
(117) |
Mar
(157) |
Apr
(94) |
May
(42) |
Jun
(41) |
Jul
(62) |
Aug
(75) |
Sep
(46) |
Oct
(72) |
Nov
(74) |
Dec
(25) |
2006 |
Jan
(34) |
Feb
(18) |
Mar
(84) |
Apr
(40) |
May
(19) |
Jun
(43) |
Jul
(59) |
Aug
(101) |
Sep
(123) |
Oct
(49) |
Nov
(80) |
Dec
(18) |
2007 |
Jan
(28) |
Feb
|
Mar
(1) |
Apr
(25) |
May
(11) |
Jun
(8) |
Jul
(9) |
Aug
(12) |
Sep
(13) |
Oct
(17) |
Nov
(73) |
Dec
(15) |
2008 |
Jan
(108) |
Feb
(34) |
Mar
(112) |
Apr
(82) |
May
(56) |
Jun
(74) |
Jul
(31) |
Aug
(72) |
Sep
(47) |
Oct
(9) |
Nov
(17) |
Dec
(11) |
2009 |
Jan
(139) |
Feb
(33) |
Mar
(16) |
Apr
(10) |
May
(11) |
Jun
(6) |
Jul
(86) |
Aug
(50) |
Sep
(13) |
Oct
(27) |
Nov
(59) |
Dec
(243) |
2010 |
Jan
(61) |
Feb
(31) |
Mar
(7) |
Apr
(22) |
May
(15) |
Jun
(12) |
Jul
(13) |
Aug
(33) |
Sep
(5) |
Oct
(33) |
Nov
(27) |
Dec
(19) |
2011 |
Jan
(16) |
Feb
(41) |
Mar
(7) |
Apr
(13) |
May
|
Jun
|
Jul
(10) |
Aug
(67) |
Sep
(7) |
Oct
(23) |
Nov
(5) |
Dec
(5) |
2012 |
Jan
(40) |
Feb
(53) |
Mar
(6) |
Apr
(35) |
May
(50) |
Jun
(19) |
Jul
(43) |
Aug
(110) |
Sep
(71) |
Oct
(24) |
Nov
(13) |
Dec
(18) |
2013 |
Jan
(13) |
Feb
(9) |
Mar
(29) |
Apr
(6) |
May
(18) |
Jun
(4) |
Jul
(24) |
Aug
(25) |
Sep
(30) |
Oct
(30) |
Nov
(8) |
Dec
(6) |
2014 |
Jan
(1) |
Feb
(3) |
Mar
|
Apr
(28) |
May
(6) |
Jun
(12) |
Jul
(8) |
Aug
(14) |
Sep
(128) |
Oct
(31) |
Nov
(27) |
Dec
(19) |
2015 |
Jan
(5) |
Feb
(3) |
Mar
(11) |
Apr
(4) |
May
(10) |
Jun
|
Jul
(1) |
Aug
(11) |
Sep
(20) |
Oct
(19) |
Nov
|
Dec
(6) |
2016 |
Jan
(1) |
Feb
(1) |
Mar
(11) |
Apr
(4) |
May
|
Jun
(7) |
Jul
|
Aug
|
Sep
(6) |
Oct
(22) |
Nov
(6) |
Dec
(8) |
2017 |
Jan
(2) |
Feb
(1) |
Mar
(1) |
Apr
(2) |
May
|
Jun
(6) |
Jul
(28) |
Aug
(87) |
Sep
(4) |
Oct
(1) |
Nov
|
Dec
|
From: <ada...@gm...> - 2017-08-18 01:21:26
|
Ok, so I did the pull into our local "gambasbase" clone which is a "single-branch" of the "master". All worked fine and super quick. Then, I did a pull from my personal clone of "gambasbase". This one has some branches in it for our (paddys-hill) changes. That pull automagically started a merge, which is fine, but then.... it invoked vim on the commit header. That was a surprise! Not the least of which was trying to remember how the heck to get out of vim. Is there a way to turn off this "feature"? b -- B Bruen <ada...@gn... (sort of)> |
From: <ada...@gm...> - 2017-08-18 01:12:05
|
On Thu, 17 Aug 2017 17:26:26 -0700 (MST) zxMarce <d4t...@gm...> wrote: > (SQLite3 does not provide a name, tho, be warned). Isn't a sqlite db without a name an "in memory" database? b -- B Bruen <ada...@gn... (sort of)> |
From: zxMarce <d4t...@gm...> - 2017-08-18 00:26:31
|
Hi there. This is mainly intended to be tackled by Benoît, but anyone with the necessary knowledge (Toby?) please feel free to butt in. The ODBC driver can use Connection Strings since some time now. I also have a patched up module that can run successfully non-data-producing queries (the SQL_NO_DATA return code is no longer treated as an error), thanks to a bug submitted by Piccoro. Problem is in the open_database() function. When using connstrings, the database name is usually part of this string, and no .Name property is expected to be populated from the BASIC program, nor actually used. So, I'm trying to populate the property from the ODBC backend. I can successfully fetch the DB Name from the lower level database driver in use (SQLite3 does not provide a name, tho, be warned). What I cannot do, be it via copying char[] or Gambas String buffer pointers, is to get the .Name property populated back to the running BASIC program. The open_database() call has two parameters: DB_DESC *desc and DB_DATABASE *db. My best guess is that I have to fiddle with desc, but not really sure if that's correct nor exactly how. To further salt the issue, queries exist in big RDBMS that allow to hot-switch databases while connected to a server (example: USE <newDBName> in MSSQL). So, the connection's .Name property should also be "refetched" after a successful query is run. Any suggestions? -- View this message in context: http://gambas.8142.n7.nabble.com/Cannot-populate-database-Connection-Name-from-ODBC-driver-tp60002.html Sent from the gambas-devel mailing list archive at Nabble.com. |
From: PICCORO M. L. <mck...@gm...> - 2017-08-15 19:20:31
|
umm you have right!.. so then for each port gambas group can have projects per ports.. O.o! this "gambas" gitlab gropu, growup so faster! Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com 2017-08-15 15:18 GMT-04:00 Bastian Germann <bas...@fi...>: > I have created merge requests to get the patches upstream (except > gambas3-libpq.patch). The cygport defines the sourceforge release > mirrors as the place to download the Gambas source files from, so it > does not need them nearby in the file system, i.e. it is not a good idea > to keep it as a branch in the gambas repository. It is possible but not > idiomatic to have branches with no common history (orphans) in git. > > Also I want to be able to set git tags, which are global for a repo. It > would be bad to have the Cygwin package version numbers appear in one > list with the Gambas version numbers. > > I can define git as download source in the cygport instead of > sourceforge as well, which I do for development purposes. > > Am 15.08.2017 um 20:57 schrieb PICCORO McKAY Lenz: >> umm in that cases, another project under the "gambas" group can exist >> but i thing its not necesary.. i explain me: >> >> its better a branch, due i guess your Cygwin need the gambas files.. >> so with a brand you can play with devel version or stable lasted and >> your patches can be apply directly or not depends on merged changes... >> >> lest wait what said benoit and others.. >> Lenz McKAY Gerardo (PICCORO) >> http://qgqlochekone.blogspot.com >> >> >> 2017-08-15 12:06 GMT-04:00 Bastian Germann <bas...@fi...>: >>> The gambas3.cygport file in the repo is used with cygport [0] to >>> generate all the gambas3* packages that are available in the Cygwin >>> package repository [1]. >>> >>> I compile the packages in Cygwin, so no cross compilation is involved. >>> >>> Paint.NET (I cannot get any sources to build) needs the .NET environment >>> to run, which is also some hundreds of MB, so your example is flawed. >>> And it is Windows-only software, whereas Gambas expects a unix-like >>> environment to run... >>> >>> [0] https://github.com/cygwinports/cygport >>> [1] https://cygwin.com/cgi-bin2/package-grep.cgi?grep=gambas3 >>> >>> Am 15.08.2017 um 16:11 schrieb PICCORO McKAY Lenz: >>>> i do not use deeply those but how does work for gambas? can you explain more !? >>>> >>>> as i understand cywing download a "lot" of bytes to have pieces >>>> working for a single package development.. just imaginate: i want to >>>> build paint.net inside linux for guiindows.. that produces a only 6 Mb >>>> file.. good.. the cywing environment are very huge for that.. >>>> Lenz McKAY Gerardo (PICCORO) >>>> http://qgqlochekone.blogspot.com >>>> >>>> >>>> 2017-08-15 5:45 GMT-04:00 Bastian Germann <bas...@fi...>: >>>>> Hi, >>>>> >>>>> the Gambas Cygwin package that I maintain is generated from a cygport >>>>> file that is available on GitLab. As there is a gambas organization now, >>>>> maybe you want to have https://gitlab.com/bgermann/gambas-cygport >>>>> available there. If so, you can add me to the organization and I will >>>>> move it. >>>>> >>>>> Regards, >>>>> Bastian > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Gambas-devel mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gambas-devel |
From: Bastian G. <bas...@fi...> - 2017-08-15 19:18:16
|
I have created merge requests to get the patches upstream (except gambas3-libpq.patch). The cygport defines the sourceforge release mirrors as the place to download the Gambas source files from, so it does not need them nearby in the file system, i.e. it is not a good idea to keep it as a branch in the gambas repository. It is possible but not idiomatic to have branches with no common history (orphans) in git. Also I want to be able to set git tags, which are global for a repo. It would be bad to have the Cygwin package version numbers appear in one list with the Gambas version numbers. I can define git as download source in the cygport instead of sourceforge as well, which I do for development purposes. Am 15.08.2017 um 20:57 schrieb PICCORO McKAY Lenz: > umm in that cases, another project under the "gambas" group can exist > but i thing its not necesary.. i explain me: > > its better a branch, due i guess your Cygwin need the gambas files.. > so with a brand you can play with devel version or stable lasted and > your patches can be apply directly or not depends on merged changes... > > lest wait what said benoit and others.. > Lenz McKAY Gerardo (PICCORO) > http://qgqlochekone.blogspot.com > > > 2017-08-15 12:06 GMT-04:00 Bastian Germann <bas...@fi...>: >> The gambas3.cygport file in the repo is used with cygport [0] to >> generate all the gambas3* packages that are available in the Cygwin >> package repository [1]. >> >> I compile the packages in Cygwin, so no cross compilation is involved. >> >> Paint.NET (I cannot get any sources to build) needs the .NET environment >> to run, which is also some hundreds of MB, so your example is flawed. >> And it is Windows-only software, whereas Gambas expects a unix-like >> environment to run... >> >> [0] https://github.com/cygwinports/cygport >> [1] https://cygwin.com/cgi-bin2/package-grep.cgi?grep=gambas3 >> >> Am 15.08.2017 um 16:11 schrieb PICCORO McKAY Lenz: >>> i do not use deeply those but how does work for gambas? can you explain more !? >>> >>> as i understand cywing download a "lot" of bytes to have pieces >>> working for a single package development.. just imaginate: i want to >>> build paint.net inside linux for guiindows.. that produces a only 6 Mb >>> file.. good.. the cywing environment are very huge for that.. >>> Lenz McKAY Gerardo (PICCORO) >>> http://qgqlochekone.blogspot.com >>> >>> >>> 2017-08-15 5:45 GMT-04:00 Bastian Germann <bas...@fi...>: >>>> Hi, >>>> >>>> the Gambas Cygwin package that I maintain is generated from a cygport >>>> file that is available on GitLab. As there is a gambas organization now, >>>> maybe you want to have https://gitlab.com/bgermann/gambas-cygport >>>> available there. If so, you can add me to the organization and I will >>>> move it. >>>> >>>> Regards, >>>> Bastian |
From: PICCORO M. L. <mck...@gm...> - 2017-08-15 18:57:32
|
umm in that cases, another project under the "gambas" group can exist but i thing its not necesary.. i explain me: its better a branch, due i guess your Cygwin need the gambas files.. so with a brand you can play with devel version or stable lasted and your patches can be apply directly or not depends on merged changes... lest wait what said benoit and others.. Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com 2017-08-15 12:06 GMT-04:00 Bastian Germann <bas...@fi...>: > The gambas3.cygport file in the repo is used with cygport [0] to > generate all the gambas3* packages that are available in the Cygwin > package repository [1]. > > I compile the packages in Cygwin, so no cross compilation is involved. > > Paint.NET (I cannot get any sources to build) needs the .NET environment > to run, which is also some hundreds of MB, so your example is flawed. > And it is Windows-only software, whereas Gambas expects a unix-like > environment to run... > > [0] https://github.com/cygwinports/cygport > [1] https://cygwin.com/cgi-bin2/package-grep.cgi?grep=gambas3 > > Am 15.08.2017 um 16:11 schrieb PICCORO McKAY Lenz: >> i do not use deeply those but how does work for gambas? can you explain more !? >> >> as i understand cywing download a "lot" of bytes to have pieces >> working for a single package development.. just imaginate: i want to >> build paint.net inside linux for guiindows.. that produces a only 6 Mb >> file.. good.. the cywing environment are very huge for that.. >> Lenz McKAY Gerardo (PICCORO) >> http://qgqlochekone.blogspot.com >> >> >> 2017-08-15 5:45 GMT-04:00 Bastian Germann <bas...@fi...>: >>> Hi, >>> >>> the Gambas Cygwin package that I maintain is generated from a cygport >>> file that is available on GitLab. As there is a gambas organization now, >>> maybe you want to have https://gitlab.com/bgermann/gambas-cygport >>> available there. If so, you can add me to the organization and I will >>> move it. >>> >>> Regards, >>> Bastian > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Gambas-devel mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gambas-devel |
From: Bastian G. <bas...@fi...> - 2017-08-15 16:30:11
|
The gambas3.cygport file in the repo is used with cygport [0] to generate all the gambas3* packages that are available in the Cygwin package repository [1]. I compile the packages in Cygwin, so no cross compilation is involved. Paint.NET (I cannot get any sources to build) needs the .NET environment to run, which is also some hundreds of MB, so your example is flawed. And it is Windows-only software, whereas Gambas expects a unix-like environment to run... [0] https://github.com/cygwinports/cygport [1] https://cygwin.com/cgi-bin2/package-grep.cgi?grep=gambas3 Am 15.08.2017 um 16:11 schrieb PICCORO McKAY Lenz: > i do not use deeply those but how does work for gambas? can you explain more !? > > as i understand cywing download a "lot" of bytes to have pieces > working for a single package development.. just imaginate: i want to > build paint.net inside linux for guiindows.. that produces a only 6 Mb > file.. good.. the cywing environment are very huge for that.. > Lenz McKAY Gerardo (PICCORO) > http://qgqlochekone.blogspot.com > > > 2017-08-15 5:45 GMT-04:00 Bastian Germann <bas...@fi...>: >> Hi, >> >> the Gambas Cygwin package that I maintain is generated from a cygport >> file that is available on GitLab. As there is a gambas organization now, >> maybe you want to have https://gitlab.com/bgermann/gambas-cygport >> available there. If so, you can add me to the organization and I will >> move it. >> >> Regards, >> Bastian |
From: PICCORO M. L. <mck...@gm...> - 2017-08-15 14:11:20
|
i do not use deeply those but how does work for gambas? can you explain more !? as i understand cywing download a "lot" of bytes to have pieces working for a single package development.. just imaginate: i want to build paint.net inside linux for guiindows.. that produces a only 6 Mb file.. good.. the cywing environment are very huge for that.. Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com 2017-08-15 5:45 GMT-04:00 Bastian Germann <bas...@fi...>: > Hi, > > the Gambas Cygwin package that I maintain is generated from a cygport > file that is available on GitLab. As there is a gambas organization now, > maybe you want to have https://gitlab.com/bgermann/gambas-cygport > available there. If so, you can add me to the organization and I will > move it. > > Regards, > Bastian > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Gambas-devel mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gambas-devel |
From: Bastian G. <bas...@fi...> - 2017-08-15 10:10:13
|
Hi, the Gambas Cygwin package that I maintain is generated from a cygport file that is available on GitLab. As there is a gambas organization now, maybe you want to have https://gitlab.com/bgermann/gambas-cygport available there. If so, you can add me to the organization and I will move it. Regards, Bastian |
From: PICCORO M. L. <mck...@gm...> - 2017-08-14 19:19:17
|
ahh! ok.. thanks for clarify! Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com 2017-08-14 15:11 GMT-04:00 Adrien Prokopowicz <adr...@gm...>: > Le Mon, 14 Aug 2017 21:01:42 +0200, PICCORO McKAY Lenz > <mck...@gm...> a écrit: > >> reading the svn wiki and viewing the subversion repository i now >> understantd a important organization piece : the commit log! >> >> in git there's two operations that does not conform the LOG format .. >> the sync/merge local and the sync/pull merge remote >> >> so a new log format must (i think) define for this king of "commits" >> in the repository, see it!: >> >> 'Merge branch 'master' of gitlab.com:gambas/gambas' >> >> in the commit >> https://gitlab.com/gambas/gambas/commit/2343dd7899c74a1314e05d06495de15a55160b2d >> >> does not follow the log format... also the pull merge and merge >> request must also be in same format for external contribution to >> follow old log in wiki >> >> Lenz McKAY Gerardo (PICCORO) >> http://qgqlochekone.blogspot.com > > > From my understanding, the commit log format is only used to make the > Release Changelog. > Everything that doesn't start with the tags will just get ignored. Which is > the right > thing to do for merge commits. :-) > > -- > Adrien Prokopowicz > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Gambas-devel mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gambas-devel |
From: Adrien P. <adr...@gm...> - 2017-08-14 19:11:36
|
Le Mon, 14 Aug 2017 21:01:42 +0200, PICCORO McKAY Lenz <mck...@gm...> a écrit: > reading the svn wiki and viewing the subversion repository i now > understantd a important organization piece : the commit log! > > in git there's two operations that does not conform the LOG format .. > the sync/merge local and the sync/pull merge remote > > so a new log format must (i think) define for this king of "commits" > in the repository, see it!: > > 'Merge branch 'master' of gitlab.com:gambas/gambas' > > in the commit > https://gitlab.com/gambas/gambas/commit/2343dd7899c74a1314e05d06495de15a55160b2d > > does not follow the log format... also the pull merge and merge > request must also be in same format for external contribution to > follow old log in wiki > > Lenz McKAY Gerardo (PICCORO) > http://qgqlochekone.blogspot.com From my understanding, the commit log format is only used to make the Release Changelog. Everything that doesn't start with the tags will just get ignored. Which is the right thing to do for merge commits. :-) -- Adrien Prokopowicz |
From: PICCORO M. L. <mck...@gm...> - 2017-08-14 19:01:50
|
reading the svn wiki and viewing the subversion repository i now understantd a important organization piece : the commit log! in git there's two operations that does not conform the LOG format .. the sync/merge local and the sync/pull merge remote so a new log format must (i think) define for this king of "commits" in the repository, see it!: 'Merge branch 'master' of gitlab.com:gambas/gambas' in the commit https://gitlab.com/gambas/gambas/commit/2343dd7899c74a1314e05d06495de15a55160b2d does not follow the log format... also the pull merge and merge request must also be in same format for external contribution to follow old log in wiki Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com |
From: PICCORO M. L. <mck...@gm...> - 2017-08-13 15:12:32
|
2017-08-13 4:14 GMT-04:00 ada...@gm... <ada...@gm...>: > 1) I am pretty impressed with the Git/GitLab approach. I had an "experience" with Git a couple of > years ago and hated it. The GitLab site makes it so much easier. So +++ gitlab interface its the most feature rich! unfortunatelly there's no good gui client like rapidsvn for git counterpart > 2) An item of concern (to me) is the appears to be no road map for moving Gambas to Git. Yeah maybe the roadmap was a feature Initiative and i think its not so "critical" git (as i see from you) are more flexible rather than subversion.. > Documentation!!! How can I help? I can write wiki stuff in the evenings to wind down. http://gambaswiki.org/wiki/doc/markdown#t9 very consencus and clear, there's more but for start its enought until When will the sourceforge repo disappear? Is there a disaster recovery plan (should, say, the GitLab repo get corrupted)? > 3) I use modified versions of the IDE, several components and some of the mainline gambas code. > The reasons for this are arcane, for example my gb.db.postgres is modified to take advantage of > postgresql features not supported in other rdbms' and the mods are therefore philosophically at odds > with the gambas gb.db common interface approach, so they won't be committed. Since we (here) > design in and use postgres ONLY(! corporate rule :-) this is fine for us. I'm very interesting on your local patches.. > To enable this, I have a local SVN repository cloned off the Sourceforge one and can adequately in gitlab with a simple button called "fork" you can track the repository and now best: with a simple configuration, that fork can update automatically, and your changes can be in a specific branch, inclusivelly you can made this into the main repository and gambas developers can take advantage of your changes! > 3a) Can I run a local repository clone off the GitLab repo? yeah, please take a read : http://gambaswiki.org/wiki/howto/git#t3 > Then off that, I might have some other branches where I (me) can play with other changes while Felicity and my other developers can use a Gambas from "local"? Have I got the right idea? Is this feasible? Please take in consideration that in git branches are "virtual references" > 3b) Here's another example. I have a modified version of the FProperty class from the IDE that supports something I suggested a few years ago - "custom" property editors. There are two reasons why it was not committed to the Sourceforge repo. a) Benoît did not like the idea at the time and b) I had to redesign most of the class code, mainly because I couldn't understand how the original works, which has resulted in a FProperty class that is completely different to the official one. SVN/eSVN handles this fairly easily as the file is marked "Replaced" and no merging or anything is required (until someone changes the official version for some reason! Given that the last change was rev 7730, I live in hope.) Can Git handle that situation? can use the "Fork" button. o inclusive make a local git BARE copy and upload as original a fork its like a copy but with author change... and for AUTOMATIC update to your repository use the integrate tab of thesettings. to track use branches.. and mantain original branches to manage differences.. also the original master branch into your own a add a second remote to your local copy, using this command git remote add upstream https://gitlab.com/gambas/gambas.git thas are also writable but only in your copy.. |
From: <ada...@gm...> - 2017-08-13 14:31:06
|
Thanks for that info Adrien, you have cleared up a lot of what I thought but could not confirm to my own satisfaction from reading/playing. To save you having to wade through the below here are a few comments (referenced to my original points). 2) I agree and would like to help with the How To. (I tried to "translate" Piccoro's well intentioned draft page but got lost.) I am currently drafting a set of wiki pages locally (using Olivier Cruille' s most excellent markdown editor from the farm!) I feel we may need two pages (at least) one for contributors and one for non-contributing users. There is just too much to write for each one for a single page and it might be confusing for the latter to be subjected to the workflows, updates etc etc. Your thoughts? 2) Regarding the r/o status of the sourceforge repository. Ah I see, so I guess I'll just limit us to "emergency patching" for now. 2) DRP. Ok, that makes me a lot more confident! 3) and 3a) (Local clone) Thank you very much for that info - much clearer now! 3b) I am still not sure whether I am happy about the loss of the "replaced" status from SVN. :-( I guess I'll just wait and see). P.S. I generally use diffuse, which I have managed to integrate with most of the GUI client's I've tried so that is some pain killer I suppose. 3c) revision ID's : ah now I get it! I guess I'll get used to it. 4) comments (snip pasted from below) > This is because all Git tools show the first line as a short commit description > (like here : https://gitlab.com/gambas/gambas/commits/master), and just > having the first section tag is unhelpful at best. > Since Benoît's standard ignores non-prefixed lines, it doesn't matter and > is skipped when making the final revision changelog. :) Hmmmmmm. My experience is converse. I like to see what "area" a change affects as a summary and the details I can review in the fullness of time. For example, a change to [GB.JIT] is not going to worry me too much as we don;t use it. (There are reasons.) But a change to [GB.DB] or [GB.DB.POSTGRES] will affect us so I want to review that asap. How about a compromise? Put the section tag and a short description on the first line. P.S. I thought that the SVN could enforce the commit comments because some years ago I set up a little "template" in esvn to "enforce" it - I just forgot all about that. I see some of the clients seem to have a similar feature, I look at them some time. 5) (clients) Yes. they all do seem to be strong in some areas and &#$^&# weak in others. Giggle, for example is great at browsing the change history but lousy at managing commits, etc. Just thought someone might have found the "magic" answer. 5) (gambas IDE integration) Love to help! With some reservations I know my way around the IDE pretty well. Let me know when your component is usable. (Actually I really should focus on that autotools packaging fix though.) Thanks again. bruce On Sun, 13 Aug 2017 12:38:55 +0200 "Adrien Prokopowicz" <adr...@gm...> wrote: > Le Sun, 13 Aug 2017 10:14:48 +0200, ada...@gm... > <ada...@gm...> a écrit: > > > I have had a reasonably good play with the GitLab repository over the > > last couple of days. So here's a few comments and questions. > > > > 1) I am pretty impressed with the Git/GitLab approach. I had an > > "experience" with Git a couple of years ago and hated it. The GitLab > > site makes it so much easier. So +++ > > 2) An item of concern (to me) is the appears to be no road map for > > moving Gambas to Git. As I said elsewhere, we are about to go into our > > busiest time of year and the thought of having to move my development > > system and our 6 sponsor clients to git in an unknown timeline scares > > me. As Adrien said somewhere in this list, there is still a lot to be > > done, it's not just a matter of moving the source. Documentation!!! How > > can I help? I can write wiki stuff in the evenings to wind down. > > Indeed, we need a proper "How To Git" page on the wiki, that explains the > following : > - How to get the source from the repo (git clone, this one is easy) > - How to contribute (for external developers) : forking the repo, the > commit log > format, staying up-to-date, creating merge requests, etc. > > > When will the sourceforge repo disappear? > > As Benoît said, the sourceforge repo is just read-only, and I don't think > it will > be ever deleted (unless SourceForge goes down, of course). > > > Is there a disaster recovery plan (should, say, the GitLab repo get > > corrupted)? > > I don't think there ever was a proper disaster recovery plan with > SourceForge either, > but the nature of Git makes it so everyone having a copy of the repo also > have the > full history of the branch(es) they're on, so we can push it elsewhere if > needed. > > (Actually, it's possible to make a clone without the full history using the > --depth=1 argument when cloning, but the default is to get the full > history). > > > 3) I use modified versions of the IDE, several components and some of > > the mainline gambas code. The reasons for this are arcane, for example > > my gb.db.postgres is modified to take advantage of postgresql features > > not supported in other rdbms' and the mods are therefore philosophically > > at odds with the gambas gb.db common interface approach, so they won't > > be committed. Since we (here) design in and use postgres ONLY(! > > corporate rule :-) this is fine for us. To enable this, I have a local > > SVN repository cloned off the Sourceforge one and can adequately manage > > our differences with the eSVN tool. So, > > 3a) Can I run a local repository clone off the GitLab repo? If so, it > > looks like an even better approach than what we do now. I could > > envisage that we would have a close of "master" on our dev server with > > a main branch "local" where I can manage our differences. Then off > > that, I might have some other branches where I (me) can play with other > > changes while Felicity and my other developers can use a Gambas from > > "local"? Have I got the right idea? Is this feasible? > > You can definitely do this, on your own server, but GitLab supports it > too. :) > > In GitLab, on the repository's page, you can click the "Fork" button. > It will create a copy of the Gambas repository to your account. You can > then > clone this repository on your machine and push any commits you want, it > will > only affect your copy. > > In order to stay up-to-date with the main repository, you will have to > merge > the original master branch into your own. To do this, you can add a second > (read-only) remote to your local copy, using this command : > > git remote add upstream https://gitlab.com/gambas/gambas.git > > I called the remote "upstream" here, but you can call it as you want. > (You can also use SSH, I just put the HTTPS here because credentials are > not > required to use it). > > Then, when you are on your master branch, you can ask git to merge the > master > branch from the original repository this way : > > git pull upstream master > > It then works like a regular merge, you only have to do this from time to > time > whenever you want to update your Gambas version. > > If you do not want to do this using GitLab but on one of your own servers > instead, > you will first have to set up a bare (i.e. empty) Git repository on your > server : > > https://git-scm.com/book/it/v2/Git-on-the-Server-Setting-Up-the-Server > > When it is done, use the local copy of the Gambas repo you (may have) > already > cloned, and add an origin that points to your server, using regular SSH : > > git remote add bruceserver > gi...@br...:wherever/is/your/repo/gambas.git > > Then you can clone it, and add the original repo as a remote just like > above with > GitLab. > > This actually is common practice in OSS projects (except for the > self-hosted version), > so this will certainly end up in the contributing guide on the wiki. > > > 3b) Here's another example. I have a modified version of the FProperty > > class from the IDE that supports something I suggested a few years ago - > > "custom" property editors. There are two reasons why it was not > > committed to the Sourceforge repo. a) Benoît did not like the idea at > > the time and b) I had to redesign most of the class code, mainly because > > I couldn't understand how the original works, which has resulted in a > > FProperty class that is completely different to the official one. > > SVN/eSVN handles this fairly easily as the file is marked "Replaced" and > > no merging or anything is required (until someone changes the official > > version for some reason! Given that the last change was rev 7730, I live > > in hope.) Can Git handle that situation? > > From my experience, Git handles very well 90% of the merges. For completely > different files however, it will stop halfway through the merge, and mark > some files as "conflicting". You can then use the `git mergetool` command, > which will walk you through each conflicting file using your favorite diff > program > (I personally use KDiff3, but it supports many more). > When done, you just commit your changes, and it's merged and ready to push. > > > 3c) One shortcoming appears to me to be the way commits are identified. > > I mean it obviously works and that but I miss the SVN rev number which > > was sequential and relevant across all branches and most importantly was > > "human digestible". Looking at the recent GitLab commits, the revision > > id's appear to be things like "dcabf06c" ( Fabian's [GB.TERM.FORM] * > > NEW: New TermListBox widget.) Is there some logic to these random > > looking id's? > > What you have here is the "short" commit ID (which is enough 99% of the > time). > The full ID is actually this : dcabf06cbf725137810408ed7c10c167b6863956. > > The logic behind those ids is basically "please don't collide". Because > Git is > decentralized in nature (see the above examples of across-origins merges > and commits), > you cannot have both a sequential and unique revision number. > > This is even the case on a single repository : if users A and B both > commit to their > local repositories, since Git doesn't know about each other's changes > (until they get > pushed and pulled), it cannot just do rev+1 like SVN does (you can think > of Git as > peer-to-peer, while SVN is just client/server). > > However, you can use `git rev-list --count HEAD` to count the number of > commits since > the beginning. This number is not reliable for representing a specific > commit, but it > can vaguely tell you how behind you are from recent changes. > GitLab also creates a small visual representation of "x commits behind / x > commits > ahead" on its branch list page > (https://gitlab.com/gambas/gambas/branches), which can > be useful too. > > > 4) Commit comments!!! The SVN style was so easy to follow! Keep the > > standard! Can it be enforced in Git? > > The commit comment style is actually a format enforced by Benoît, it has > nothing to > do with SVN. > I actually like it a lot, and I have already used it in a number of other > Git projects. > I only apply a small change to it : I use the first line as a short > description of what > the commit is, before adding the full changelog. > > This is because all Git tools show the first line as a short commit > description > (like here : https://gitlab.com/gambas/gambas/commits/master), and just > having the first > section tag is unhelpful at best. > Since Benoît's standard ignores non-prefixed lines, it doesn't matter and > is skipped when > making the final revision changelog. :) > > > Ah wait! One more! > > 5) Git clients. I have tried the following: > > * gitk - not bad > > * qgit - better > > * giggle - feature rich and functionally poor, but the best change > > browser of the three > > (and several CLI front ends). > > Any other suggestions (for managing my local clone) ? > > This is my personal opinion, but I have not found a single standalone git > client > on linux that I like (especially for viewing changes before committing). > Oddly enough, > I like the Git tools integrated in IDEs much better. I've used QtCreator, > NetBeans, > The JetBrains IDEs and probably others I forgot. > > So for now I use mostly the command line, but in KDE I also use the small > Git > integration plugin for Dolphin, and with a small ZSH integration that shows > the Git current branch & working copy status in my prompt. > > I am currently prototyping a Gambas component that interfaces with > libgit2, so we > can have a proper integration within the IDE, and why not make a Gambas git > graphical client in the future. :-) > > -- > Adrien Prokopowicz > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Gambas-devel mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gambas-devel -- B Bruen <ada...@gn... (sort of)> |
From: <d4t...@gm...> - 2017-08-13 13:03:08
|
+1 TIA zxMarce On Aug 13, 2017, 09:57, at 09:57, Gianluigi <bag...@gm...> wrote: >Hi Benoit, > >I apologize for ignorance but I have never used Git. >To update the Trunk, what should I do now? >To subscribe to the new ML? >To report a bug? >Write access is only for participating in the code, or? > >Regards >Gianluigi > >2017-08-12 20:10 GMT+02:00 Benoît Minisini via Gambas-user < >gam...@li...>: > >> Hi, >> >> The Gambas source repository is currently moving from SourceForge to >> GitLab. >> >> The Subversion repository is now read-only. >> >> The new git repository is at https://gitlab.com/gambas/gambas >> >> If you want a write access to the GitLab repository, sign in to >GitLab and >> give me your account. >> >> The first 'gambas' is the name of the group of GitLab users. >> >> The second 'gambas' is the name of the project. >> >> Regards, >> >> -- >> Benoît Minisini >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Gambas-user mailing list >> Gam...@li... >> https://lists.sourceforge.net/lists/listinfo/gambas-user >> >------------------------------------------------------------------------------ >Check out the vibrant tech community on one of the world's most >engaging tech sites, Slashdot.org! http://sdm.link/slashdot >_______________________________________________ >Gambas-user mailing list >Gam...@li... >https://lists.sourceforge.net/lists/listinfo/gambas-user |
From: Adrien P. <adr...@gm...> - 2017-08-13 10:39:07
|
Le Sun, 13 Aug 2017 10:14:48 +0200, ada...@gm... <ada...@gm...> a écrit: > I have had a reasonably good play with the GitLab repository over the > last couple of days. So here's a few comments and questions. > > 1) I am pretty impressed with the Git/GitLab approach. I had an > "experience" with Git a couple of years ago and hated it. The GitLab > site makes it so much easier. So +++ > 2) An item of concern (to me) is the appears to be no road map for > moving Gambas to Git. As I said elsewhere, we are about to go into our > busiest time of year and the thought of having to move my development > system and our 6 sponsor clients to git in an unknown timeline scares > me. As Adrien said somewhere in this list, there is still a lot to be > done, it's not just a matter of moving the source. Documentation!!! How > can I help? I can write wiki stuff in the evenings to wind down. Indeed, we need a proper "How To Git" page on the wiki, that explains the following : - How to get the source from the repo (git clone, this one is easy) - How to contribute (for external developers) : forking the repo, the commit log format, staying up-to-date, creating merge requests, etc. > When will the sourceforge repo disappear? As Benoît said, the sourceforge repo is just read-only, and I don't think it will be ever deleted (unless SourceForge goes down, of course). > Is there a disaster recovery plan (should, say, the GitLab repo get > corrupted)? I don't think there ever was a proper disaster recovery plan with SourceForge either, but the nature of Git makes it so everyone having a copy of the repo also have the full history of the branch(es) they're on, so we can push it elsewhere if needed. (Actually, it's possible to make a clone without the full history using the --depth=1 argument when cloning, but the default is to get the full history). > 3) I use modified versions of the IDE, several components and some of > the mainline gambas code. The reasons for this are arcane, for example > my gb.db.postgres is modified to take advantage of postgresql features > not supported in other rdbms' and the mods are therefore philosophically > at odds with the gambas gb.db common interface approach, so they won't > be committed. Since we (here) design in and use postgres ONLY(! > corporate rule :-) this is fine for us. To enable this, I have a local > SVN repository cloned off the Sourceforge one and can adequately manage > our differences with the eSVN tool. So, > 3a) Can I run a local repository clone off the GitLab repo? If so, it > looks like an even better approach than what we do now. I could > envisage that we would have a close of "master" on our dev server with > a main branch "local" where I can manage our differences. Then off > that, I might have some other branches where I (me) can play with other > changes while Felicity and my other developers can use a Gambas from > "local"? Have I got the right idea? Is this feasible? You can definitely do this, on your own server, but GitLab supports it too. :) In GitLab, on the repository's page, you can click the "Fork" button. It will create a copy of the Gambas repository to your account. You can then clone this repository on your machine and push any commits you want, it will only affect your copy. In order to stay up-to-date with the main repository, you will have to merge the original master branch into your own. To do this, you can add a second (read-only) remote to your local copy, using this command : git remote add upstream https://gitlab.com/gambas/gambas.git I called the remote "upstream" here, but you can call it as you want. (You can also use SSH, I just put the HTTPS here because credentials are not required to use it). Then, when you are on your master branch, you can ask git to merge the master branch from the original repository this way : git pull upstream master It then works like a regular merge, you only have to do this from time to time whenever you want to update your Gambas version. If you do not want to do this using GitLab but on one of your own servers instead, you will first have to set up a bare (i.e. empty) Git repository on your server : https://git-scm.com/book/it/v2/Git-on-the-Server-Setting-Up-the-Server When it is done, use the local copy of the Gambas repo you (may have) already cloned, and add an origin that points to your server, using regular SSH : git remote add bruceserver gi...@br...:wherever/is/your/repo/gambas.git Then you can clone it, and add the original repo as a remote just like above with GitLab. This actually is common practice in OSS projects (except for the self-hosted version), so this will certainly end up in the contributing guide on the wiki. > 3b) Here's another example. I have a modified version of the FProperty > class from the IDE that supports something I suggested a few years ago - > "custom" property editors. There are two reasons why it was not > committed to the Sourceforge repo. a) Benoît did not like the idea at > the time and b) I had to redesign most of the class code, mainly because > I couldn't understand how the original works, which has resulted in a > FProperty class that is completely different to the official one. > SVN/eSVN handles this fairly easily as the file is marked "Replaced" and > no merging or anything is required (until someone changes the official > version for some reason! Given that the last change was rev 7730, I live > in hope.) Can Git handle that situation? From my experience, Git handles very well 90% of the merges. For completely different files however, it will stop halfway through the merge, and mark some files as "conflicting". You can then use the `git mergetool` command, which will walk you through each conflicting file using your favorite diff program (I personally use KDiff3, but it supports many more). When done, you just commit your changes, and it's merged and ready to push. > 3c) One shortcoming appears to me to be the way commits are identified. > I mean it obviously works and that but I miss the SVN rev number which > was sequential and relevant across all branches and most importantly was > "human digestible". Looking at the recent GitLab commits, the revision > id's appear to be things like "dcabf06c" ( Fabian's [GB.TERM.FORM] * > NEW: New TermListBox widget.) Is there some logic to these random > looking id's? What you have here is the "short" commit ID (which is enough 99% of the time). The full ID is actually this : dcabf06cbf725137810408ed7c10c167b6863956. The logic behind those ids is basically "please don't collide". Because Git is decentralized in nature (see the above examples of across-origins merges and commits), you cannot have both a sequential and unique revision number. This is even the case on a single repository : if users A and B both commit to their local repositories, since Git doesn't know about each other's changes (until they get pushed and pulled), it cannot just do rev+1 like SVN does (you can think of Git as peer-to-peer, while SVN is just client/server). However, you can use `git rev-list --count HEAD` to count the number of commits since the beginning. This number is not reliable for representing a specific commit, but it can vaguely tell you how behind you are from recent changes. GitLab also creates a small visual representation of "x commits behind / x commits ahead" on its branch list page (https://gitlab.com/gambas/gambas/branches), which can be useful too. > 4) Commit comments!!! The SVN style was so easy to follow! Keep the > standard! Can it be enforced in Git? The commit comment style is actually a format enforced by Benoît, it has nothing to do with SVN. I actually like it a lot, and I have already used it in a number of other Git projects. I only apply a small change to it : I use the first line as a short description of what the commit is, before adding the full changelog. This is because all Git tools show the first line as a short commit description (like here : https://gitlab.com/gambas/gambas/commits/master), and just having the first section tag is unhelpful at best. Since Benoît's standard ignores non-prefixed lines, it doesn't matter and is skipped when making the final revision changelog. :) > Ah wait! One more! > 5) Git clients. I have tried the following: > * gitk - not bad > * qgit - better > * giggle - feature rich and functionally poor, but the best change > browser of the three > (and several CLI front ends). > Any other suggestions (for managing my local clone) ? This is my personal opinion, but I have not found a single standalone git client on linux that I like (especially for viewing changes before committing). Oddly enough, I like the Git tools integrated in IDEs much better. I've used QtCreator, NetBeans, The JetBrains IDEs and probably others I forgot. So for now I use mostly the command line, but in KDE I also use the small Git integration plugin for Dolphin, and with a small ZSH integration that shows the Git current branch & working copy status in my prompt. I am currently prototyping a Gambas component that interfaces with libgit2, so we can have a proper integration within the IDE, and why not make a Gambas git graphical client in the future. :-) -- Adrien Prokopowicz |
From: <ada...@gm...> - 2017-08-13 08:15:03
|
I have had a reasonably good play with the GitLab repository over the last couple of days. So here's a few comments and questions. 1) I am pretty impressed with the Git/GitLab approach. I had an "experience" with Git a couple of years ago and hated it. The GitLab site makes it so much easier. So +++ 2) An item of concern (to me) is the appears to be no road map for moving Gambas to Git. As I said elsewhere, we are about to go into our busiest time of year and the thought of having to move my development system and our 6 sponsor clients to git in an unknown timeline scares me. As Adrien said somewhere in this list, there is still a lot to be done, it's not just a matter of moving the source. Documentation!!! How can I help? I can write wiki stuff in the evenings to wind down. When will the sourceforge repo disappear? Is there a disaster recovery plan (should, say, the GitLab repo get corrupted)? 3) I use modified versions of the IDE, several components and some of the mainline gambas code. The reasons for this are arcane, for example my gb.db.postgres is modified to take advantage of postgresql features not supported in other rdbms' and the mods are therefore philosophically at odds with the gambas gb.db common interface approach, so they won't be committed. Since we (here) design in and use postgres ONLY(! corporate rule :-) this is fine for us. To enable this, I have a local SVN repository cloned off the Sourceforge one and can adequately manage our differences with the eSVN tool. So, 3a) Can I run a local repository clone off the GitLab repo? If so, it looks like an even better approach than what we do now. I could envisage that we would have a close of "master" on our dev server with a main branch "local" where I can manage our differences. Then off that, I might have some other branches where I (me) can play with other changes while Felicity and my other developers can use a Gambas from "local"? Have I got the right idea? Is this feasible? 3b) Here's another example. I have a modified version of the FProperty class from the IDE that supports something I suggested a few years ago - "custom" property editors. There are two reasons why it was not committed to the Sourceforge repo. a) Benoît did not like the idea at the time and b) I had to redesign most of the class code, mainly because I couldn't understand how the original works, which has resulted in a FProperty class that is completely different to the official one. SVN/eSVN handles this fairly easily as the file is marked "Replaced" and no merging or anything is required (until someone changes the official version for some reason! Given that the last change was rev 7730, I live in hope.) Can Git handle that situation? 3c) One shortcoming appears to me to be the way commits are identified. I mean it obviously works and that but I miss the SVN rev number which was sequential and relevant across all branches and most importantly was "human digestible". Looking at the recent GitLab commits, the revision id's appear to be things like "dcabf06c" ( Fabian's [GB.TERM.FORM] * NEW: New TermListBox widget.) Is there some logic to these random looking id's? 4) Commit comments!!! The SVN style was so easy to follow! Keep the standard! Can it be enforced in Git? That's enough for now, more later. (I'm busy trying to translate a certain wiki page.) Ah wait! One more! 5) Git clients. I have tried the following: * gitk - not bad * qgit - better * giggle - feature rich and functionally poor, but the best change browser of the three (and several CLI front ends). Any other suggestions (for managing my local clone) ? regards bruce -- B Bruen <ada...@gn... (sort of)> |
From: PICCORO M. L. <mck...@gm...> - 2017-08-13 06:43:05
|
connection strings are since gabmas 3.7 ? this will break backguard compatiblity... about odbc and some bugs present, the multicursor fetch are a freedts limit, already reported and tested by me among others in freetds project contribution > Le 16/10/2015 ? 19:20, ML a ?crit : >> >> Beno?t, >> >> Well, I was speaking about SQL-92 and the like... >> >> ODBC has a way to fetch a block of rows. You can set how many. Then, it >> will retrieve (up to) that many rows from the rowset. >> You can, IIRC, also specify the starting offset. All this, of course, as >> long as the Driver or RDBM provides scrollable cursors. >> Mind you, I never tried a row-block fetch, and it will be a demanding >> 'challenge' to overcome. My guess is that it will take some time. >> >> Please tell me how can gb.db.odbc know whether someone used the >> DB.Limit() property, so I can make the next fetch a row-block fetch, and >> how to recognize a "go back to retrieving 1 row at a time" mode change. >> Related to that, one of the things that still escape me is which calls >> in gb.db map to which (block of) calls in gb.db.odbc. That, and which >> high level Gambas calls map to which gb.db (block of) calls. >> >> Regards, >> |
From: <ada...@gm...> - 2017-08-13 06:09:00
|
Benoît/Adrien, Could you please add me as a developer to the gitlab project. My GitLab id is "brucebruen ". Do you need anything else? I have a couple of things in the pipeline but don't have much free time at the moment, so little will happen for a while. The major contribution I am working on at the moment (when time allows) is an update to the autotools packager to comply with the new naming and destinations for Library projects. I have got it some way but am struggling with sed trying to derive the proper name for the package and library name and path... So I thought maybe I could branch off master and somebody with better sed skills (really, any sed skills would be better than mine) could help out. regards bruce -- B Bruen <ada...@gn... (sort of)> |
From: PICCORO M. L. <mck...@gm...> - 2017-08-13 05:44:04
|
From: Tobias Boege <ta...@gm...> > Message-ID: <20170812231859.GD541@aurora.localdomain> > On Sat, 12 Aug 2017, PICCORO McKAY Lenz wrote: >> I saw there that the >> openssl committee has been removed, after have been Need it on my >> embedded linux .. > I haven't checked this but now that we're on git, you'll have an easy time > maintaining your own fork for legacy-openssl Gambas and the commit should > stay removed imho. > > Regards, > Tobi That's all! easy, no more No appeals, like a dictatorship ! After having accepted the change and even sent a patch and corroborated worked perfect? interesting! Support for 32-bit Motorola/IBM PowerPC (powerpc) has been removed in Stretch. So i must use for powerpc a older linux in debian, and pabkports package, i cannot "trash" the hardware due are working and perfectly! Spen 35$ on a Rasberry PI 3 B seem very cheap for you Tobi, but for us in Venezuela are VERY SPENSIVE, its a comlete lich for two persons.. so here many people that need make productive older environments withou changes need some effors and contributions, ahta that commit : https://sourceforge.net/p/gambas/code/7892/ was really need to use debian squeeze due its the most supported to run in the powerpc due recent debians and linuxes does not support I want to tell us something, in freetds, there's a sense on specific commit, support for older kernels.. why, simple connection to database direclty from embebed linuxes on mobile card computers.. that runs linux 2.6.18 will be great if Gambas can run in any environment witout making "magic" or need "hungry requeriments"... many countries does not like spend so much money on a "great software"... |
From: PICCORO M. L. <mck...@gm...> - 2017-08-13 04:48:06
|
2017-08-12 3:49 GMT-04:00 <gam...@li...>: From: "Adrien Prokopowicz" <adr...@gm...> >> Very strange: 3.10.0 tag is present in the "tags" section of the >> repository, but not when you pop down the list "switch branch/tag"... > > It's there, but the list isn't sorted in natural order, so it's right after > the 3.1.0 version. this its due 1.0 its minor rather than 10.0 to amek sense order must be 3.01.0 vs 3.10.0, i read the explanation of Adrian, very close to the subversion workflow.. i must added that in git all its technically "virtual" and the "commits" are always the point of work... unless the directory copy organization of subversion.. i make a equivalent git page of the http://gambaswiki.org/wiki/howto/svn as http://gambaswiki.org/wiki/howto/git with most close tho the svn but git are de-centralised so unless subversion, a commit its not a upload.. in git we can made many commits before made an upload.. so modify as prefer.. i only put info to compilation related > > I didn't push the branches for the stable versions, since the tags have the > same purpose : you can switch to any tag, and create a branch from there if > you want to make changes to an older version. > > (Actually, you can switch to any commit you want and create a branch from > there : > commits are kind of like ref-counted, and a tag is just a named reference > to a > commit). > > However, if I missed something and there is something needed in these > branches, > I can push them back. > > For tagging new releases, as we've discussed in previous messages, it's > all done > from the "stable" branch : right now it contains the 3.10.0 version, you > can either > commit directly to it or cherry-pick commits from the master branch (i.e. > just take > specific commits instead of the whole branch, if you want only the > bugfixes to tag > a patch release, say 3.10.1). > > You can also merge the master branch into stable, which will apply all the > commits the > stable branch didn't have, in order to tag a new release, say 3.11. > > Once you're done and the stable branch contains what you want to release, > you just > have to create an annotated tag[0]. (Annotated tags have checksums and can > be signed, > unlike simple tags which are just pointers). > And then it's done. :-) > > [0] https://git-scm.com/book/en/v2/Git-Basics-Tagging > > -- > Adrien Prokopowicz > > > > ------------------------------ > > ------------------------------------------------------------------------------ > 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 113, Issue 2 > ******************************************** |
From: Tobias B. <ta...@gm...> - 2017-08-12 23:19:16
|
On Sat, 12 Aug 2017, PICCORO McKAY Lenz wrote: > I saw there that the > openssl committee has been removed, after have been Need it on my > embedded linux .. > I haven't checked this but now that we're on git, you'll have an easy time maintaining your own fork for legacy-openssl Gambas and the commit should stay removed imho. Regards, Tobi -- "There's an old saying: Don't change anything... ever!" -- Mr. Monk |
From: PICCORO M. L. <mck...@gm...> - 2017-08-12 23:14:29
|
hi all, benoit. that's great news, long awaited, now I have more interest and expectations in the module odbc, my concern is that I cannot longer in future keep compiles "gambas" in my old linux .. I saw there that the openssl committee has been removed, after have been Need it on my embedded linux .. also was a great dessition not use github,and use gitlab, gitlab are more "free" software avocate rather thant github! Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com 2017-08-12 14:10 GMT-04:00 Benoît Minisini via Gambas-user <gam...@li...>: > Hi, > > The Gambas source repository is currently moving from SourceForge to GitLab. > > The Subversion repository is now read-only. > > The new git repository is at https://gitlab.com/gambas/gambas > > If you want a write access to the GitLab repository, sign in to GitLab and > give me your account. > > The first 'gambas' is the name of the group of GitLab users. > > The second 'gambas' is the name of the project. > > Regards, > > -- > Benoît Minisini > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Gambas-user mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gambas-user |
From: Benoît M. <ga...@us...> - 2017-08-12 18:11:06
|
Hi, The Gambas source repository is currently moving from SourceForge to GitLab. The Subversion repository is now read-only. The new git repository is at https://gitlab.com/gambas/gambas If you want a write access to the GitLab repository, sign in to GitLab and give me your account. The first 'gambas' is the name of the group of GitLab users. The second 'gambas' is the name of the project. Regards, -- Benoît Minisini |
From: PICCORO M. L. <mck...@gm...> - 2017-08-12 14:36:15
|
Hi, the gambas git repository looks great! i want to share with yours the possibility of a mirror in github or other automatically (but not necesary): gitlab has a unique feature (well mostly a "lazy" feature), can automatically mirror and track changes to another repository.. the idea its to mantain a mirror git in github! .. i dont like so much due github are more close to non-free software.. and gitlab make more for freesoftware rather thant github.. the github mirror can be only a git repo without wiki and issue (github does not have the redirection features i suggested in gitlab) well great for the git change.. great job Benoit and Adrian.. and remenber that gitlab has many features in the "integration" and "services" tab of settings |