Menu
▾
▴
naviserver-devel — Developer discussion
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(53) |
Mar
(62) |
Apr
(88) |
May
(55) |
Jun
(204) |
Jul
(52) |
Aug
|
Sep
(1) |
Oct
(94) |
Nov
(15) |
Dec
(68) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(130) |
Feb
(105) |
Mar
(34) |
Apr
(61) |
May
(41) |
Jun
(92) |
Jul
(176) |
Aug
(102) |
Sep
(247) |
Oct
(69) |
Nov
(32) |
Dec
(140) |
| 2007 |
Jan
(58) |
Feb
(51) |
Mar
(11) |
Apr
(20) |
May
(34) |
Jun
(37) |
Jul
(18) |
Aug
(60) |
Sep
(41) |
Oct
(105) |
Nov
(19) |
Dec
(14) |
| 2008 |
Jan
(3) |
Feb
|
Mar
(7) |
Apr
(5) |
May
(123) |
Jun
(5) |
Jul
(1) |
Aug
(29) |
Sep
(15) |
Oct
(21) |
Nov
(51) |
Dec
(3) |
| 2009 |
Jan
|
Feb
(36) |
Mar
(29) |
Apr
|
May
|
Jun
(7) |
Jul
(4) |
Aug
|
Sep
(4) |
Oct
|
Nov
(13) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(9) |
Apr
(11) |
May
(16) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
(7) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(92) |
Nov
(28) |
Dec
(16) |
| 2013 |
Jan
(9) |
Feb
(2) |
Mar
|
Apr
(4) |
May
(4) |
Jun
(6) |
Jul
(14) |
Aug
(12) |
Sep
(4) |
Oct
(13) |
Nov
(1) |
Dec
(6) |
| 2014 |
Jan
(23) |
Feb
(19) |
Mar
(10) |
Apr
(14) |
May
(11) |
Jun
(6) |
Jul
(11) |
Aug
(15) |
Sep
(41) |
Oct
(95) |
Nov
(23) |
Dec
(11) |
| 2015 |
Jan
(3) |
Feb
(9) |
Mar
(19) |
Apr
(3) |
May
(1) |
Jun
(3) |
Jul
(11) |
Aug
(1) |
Sep
(15) |
Oct
(5) |
Nov
(2) |
Dec
|
| 2016 |
Jan
(7) |
Feb
(11) |
Mar
(8) |
Apr
(1) |
May
(3) |
Jun
(17) |
Jul
(12) |
Aug
(3) |
Sep
(5) |
Oct
(19) |
Nov
(12) |
Dec
(6) |
| 2017 |
Jan
(30) |
Feb
(23) |
Mar
(12) |
Apr
(32) |
May
(27) |
Jun
(7) |
Jul
(13) |
Aug
(16) |
Sep
(6) |
Oct
(11) |
Nov
|
Dec
(12) |
| 2018 |
Jan
(1) |
Feb
(5) |
Mar
(6) |
Apr
(7) |
May
(23) |
Jun
(3) |
Jul
(2) |
Aug
(1) |
Sep
(6) |
Oct
(6) |
Nov
(10) |
Dec
(3) |
| 2019 |
Jan
(26) |
Feb
(15) |
Mar
(9) |
Apr
|
May
(8) |
Jun
(14) |
Jul
(10) |
Aug
(10) |
Sep
(4) |
Oct
(2) |
Nov
(20) |
Dec
(10) |
| 2020 |
Jan
(10) |
Feb
(14) |
Mar
(29) |
Apr
(11) |
May
(25) |
Jun
(21) |
Jul
(23) |
Aug
(12) |
Sep
(19) |
Oct
(6) |
Nov
(8) |
Dec
(12) |
| 2021 |
Jan
(29) |
Feb
(9) |
Mar
(8) |
Apr
(8) |
May
(2) |
Jun
(2) |
Jul
(9) |
Aug
(9) |
Sep
(3) |
Oct
(4) |
Nov
(12) |
Dec
(13) |
| 2022 |
Jan
(4) |
Feb
|
Mar
(4) |
Apr
(12) |
May
(15) |
Jun
(7) |
Jul
(10) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(8) |
Dec
|
| 2023 |
Jan
(15) |
Feb
|
Mar
(23) |
Apr
(1) |
May
(2) |
Jun
(10) |
Jul
|
Aug
(22) |
Sep
(19) |
Oct
(2) |
Nov
(20) |
Dec
|
| 2024 |
Jan
(1) |
Feb
|
Mar
(16) |
Apr
(15) |
May
(6) |
Jun
(4) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(13) |
Nov
(18) |
Dec
(6) |
| 2025 |
Jan
(12) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(11) |
Jun
(5) |
Jul
(4) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Zoran V. <zv...@ar...> - 2006-09-20 16:34:33
|
On 20.09.2006, at 18:32, Vlad Seryakov wrote: > Oh, no hurry, no switching, current SVN copy is just to get to know it > and play with it to see if it is worth switching For me it looks like weekned job, where I'd rather do something else. I thougt it to be a download, install and use. It is far from that. |
|
From: Vlad S. <vl...@cr...> - 2006-09-20 16:32:38
|
Oh, no hurry, no switching, current SVN copy is just to get to know it and play with it to see if it is worth switching Zoran Vasiljevic wrote: > On 20.09.2006, at 17:53, Bernd Eidenschink wrote: > >> If you have the client installed, simply try for a checkout: > > AH, this is really NOT simple... > > I would say, please _do_not_ switch to svn anything until > I managed to get all this (clients) installed. > > When I pull svn-client using Fink commander for Mac OSX, > it breaks with tons of unresolved packages, blablabla... > For the svn-ssl client it's even worse. I do not know > how to install this client(s) w/o installing 55 other > packages that I do not need and do not know... Its seems > like another 10 hours adventure, backing up disks, restoring > etc pp. I do not have time for this, really... > > This is just what I ment: nothing is simple. > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2006-09-20 16:32:35
|
On 20.09.2006, at 18:29, Zoran Vasiljevic wrote: > > AH, this is really NOT simple... > For the record: Reading Package Lists... Building Dependency Tree... You might want to run `apt-get -f install' to correct these: Sorry, but the following packages have unmet dependencies: storable-pm: Depends: storable-pm560 but it is not installable. For Fink users, this often means that you have attempted to install a package from the binary distribution which depends on a "Restrictive" package. See <http://fink.sourceforge.net/faq/usage- fink.php#bindist>, <http://fink.sourceforge.net/doc/users-guide/ packages.php#bin-exceptions> or storable-pm561 but it is not installable. For Fink users, this often means that you have attempted to install a package from the binary distribution which depends on a "Restrictive" package. See <http://fink.sourceforge.net/faq/usage- fink.php#bindist>, <http://fink.sourceforge.net/doc/users-guide/ packages.php#bin-exceptions> or perl580-core but it is not installable. For Fink users, this often means that you have attempted to install a package from the binary distribution which depends on a "Restrictive" package. See <http://fink.sourceforge.net/faq/usage- fink.php#bindist>, <http://fink.sourceforge.net/doc/users-guide/ packages.php#bin-exceptions> or perl581-core but it is not installable. For Fink users, this often means that you have attempted to install a package from the binary distribution which depends on a "Restrictive" package. See <http://fink.sourceforge.net/faq/usage- fink.php#bindist>, <http://fink.sourceforge.net/doc/users-guide/ packages.php#bin-exceptions> or perl584-core but it is not installable. For Fink users, this often means that you have attempted to install a package from the binary distribution which depends on a "Restrictive" package. See <http://fink.sourceforge.net/faq/usage- fink.php#bindist>, <http://fink.sourceforge.net/doc/users-guide/ packages.php#bin-exceptions> svn-client: Depends: svn-shlibs (= 1.0.6-11) but it is not going to be installed E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution). This is what I ment. |
|
From: Zoran V. <zv...@ar...> - 2006-09-20 16:29:54
|
On 20.09.2006, at 17:53, Bernd Eidenschink wrote: > > If you have the client installed, simply try for a checkout: AH, this is really NOT simple... I would say, please _do_not_ switch to svn anything until I managed to get all this (clients) installed. When I pull svn-client using Fink commander for Mac OSX, it breaks with tons of unresolved packages, blablabla... For the svn-ssl client it's even worse. I do not know how to install this client(s) w/o installing 55 other packages that I do not need and do not know... Its seems like another 10 hours adventure, backing up disks, restoring etc pp. I do not have time for this, really... This is just what I ment: nothing is simple. |
|
From: Vlad S. <vl...@cr...> - 2006-09-20 16:27:26
|
svn should support http or https, i have just one binary Zoran Vasiljevic wrote: > On 20.09.2006, at 17:53, Bernd Eidenschink wrote: > >>> It is already available, i imported all branches and tags into >>> SVN, go >>> to SF and try browse Subversion. Once everybody agree, i will re- >>> import >>> most recent CVS version. >> If you have the client installed, simply try for a checkout: > > Nothing is simple. > Do I need the svn or svn-ssl client for that? > > > > >> # svn co https://svn.sourceforge.net/svnroot/naviserver/trunk/ >> naviserver >> >> and you will get the "HEAD" aka. "trunk" (SVN) of modules/ and >> naviserver/. >> >> You can watch the dir structure with: >> >> # svn list https://svn.sourceforge.net/svnroot/naviserver/ >> branches/ >> tags/ >> trunk/ >> >> # svn list https://svn.sourceforge.net/svnroot/naviserver/tags/ >> HEAD/ >> R01/ >> R0_0/ >> V1/ >> V10/ >> before-tclvfs/ >> initial-import/ >> naviserver-4_99_0-release/ >> naviserver-4_99_1-release/ >> nspostgres-4/ >> >> If you plan to integrate Javascript, you would "tag" like: >> >> svn copy https://svn.sourceforge.net/svnroot/naviserver/trunk/ >> naviserver \ >> https://svn.sourceforge.net/svnroot/naviserver/tags/before-javascript >> >> It's a cheap copy, as long as you don't commit into the "tag" >> directory (what >> would transform it into a branch). Simple thing. >> >> Diff local copy against a previous revision of a file: >> svn diff -r PREV <file> >> ("PREV" as shortcut, as well as number). >> >> One thing to get used to: The revision number FOR THE WHOLE PROJECT is >> incremented by a state change, not just the number for a file. >> >> If you want to have some shortcut like "$Id" expand in a file, in >> SVN this is >> a property, you explicitely set it. This is a onetime task. >> >> Bernd. >> >> ---------------------------------------------------------------------- >> --- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to >> share your >> opinions on IT & business topics through brief surveys -- and earn >> cash >> http://www.techsay.com/default.php? >> page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> naviserver-devel mailing list >> nav...@li... >> https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2006-09-20 16:24:34
|
On 20.09.2006, at 17:53, Bernd Eidenschink wrote: >> It is already available, i imported all branches and tags into >> SVN, go >> to SF and try browse Subversion. Once everybody agree, i will re- >> import >> most recent CVS version. > > If you have the client installed, simply try for a checkout: Nothing is simple. Do I need the svn or svn-ssl client for that? > > # svn co https://svn.sourceforge.net/svnroot/naviserver/trunk/ > naviserver > > and you will get the "HEAD" aka. "trunk" (SVN) of modules/ and > naviserver/. > > You can watch the dir structure with: > > # svn list https://svn.sourceforge.net/svnroot/naviserver/ > branches/ > tags/ > trunk/ > > # svn list https://svn.sourceforge.net/svnroot/naviserver/tags/ > HEAD/ > R01/ > R0_0/ > V1/ > V10/ > before-tclvfs/ > initial-import/ > naviserver-4_99_0-release/ > naviserver-4_99_1-release/ > nspostgres-4/ > > If you plan to integrate Javascript, you would "tag" like: > > svn copy https://svn.sourceforge.net/svnroot/naviserver/trunk/ > naviserver \ > https://svn.sourceforge.net/svnroot/naviserver/tags/before-javascript > > It's a cheap copy, as long as you don't commit into the "tag" > directory (what > would transform it into a branch). Simple thing. > > Diff local copy against a previous revision of a file: > svn diff -r PREV <file> > ("PREV" as shortcut, as well as number). > > One thing to get used to: The revision number FOR THE WHOLE PROJECT is > incremented by a state change, not just the number for a file. > > If you want to have some shortcut like "$Id" expand in a file, in > SVN this is > a property, you explicitely set it. This is a onetime task. > > Bernd. > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
|
From: Bernd E. <eid...@we...> - 2006-09-20 15:49:21
|
> It is already available, i imported all branches and tags into SVN, go > to SF and try browse Subversion. Once everybody agree, i will re-import > most recent CVS version. If you have the client installed, simply try for a checkout: # svn co https://svn.sourceforge.net/svnroot/naviserver/trunk/ naviserver and you will get the "HEAD" aka. "trunk" (SVN) of modules/ and naviserver/. You can watch the dir structure with: # svn list https://svn.sourceforge.net/svnroot/naviserver/ branches/ tags/ trunk/ # svn list https://svn.sourceforge.net/svnroot/naviserver/tags/ HEAD/ R01/ R0_0/ V1/ V10/ before-tclvfs/ initial-import/ naviserver-4_99_0-release/ naviserver-4_99_1-release/ nspostgres-4/ If you plan to integrate Javascript, you would "tag" like: svn copy https://svn.sourceforge.net/svnroot/naviserver/trunk/naviserver \ https://svn.sourceforge.net/svnroot/naviserver/tags/before-javascript It's a cheap copy, as long as you don't commit into the "tag" directory (what would transform it into a branch). Simple thing. Diff local copy against a previous revision of a file: svn diff -r PREV <file> ("PREV" as shortcut, as well as number). One thing to get used to: The revision number FOR THE WHOLE PROJECT is incremented by a state change, not just the number for a file. If you want to have some shortcut like "$Id" expand in a file, in SVN this is a property, you explicitely set it. This is a onetime task. Bernd. |
|
From: Vlad S. <vl...@cr...> - 2006-09-20 15:46:20
|
We need trunk/ only, i guess thos eold tags and branches are CVs artifacts:-))0 Zoran Vasiljevic wrote: > On 20.09.2006, at 17:30, Vlad Seryakov wrote: > >> It is already available, i imported all branches and tags into SVN, go >> to SF and try browse Subversion. Once everybody agree, i will re- >> import >> most recent CVS version. >> > > Hm > Rev. Age Author Last log entry > NAVISERVER/ 352 13 months This commit was manufactured by > cvs2svn to create branch 'NAVISERVER'. > NaviServer/ 1007 12 days This commit was manufactured by > cvs2svn to create branch 'NaviServer'. > Naviserver/ 870 2 months This commit was manufactured by > cvs2svn to create branch 'Naviserver'. > initial/ 3 19 months This commit was manufactured by cvs2svn > to create branch 'initial'. > nspostgres/ 228 15 months This commit was manufactured by > cvs2svn to create branch 'nspostgres'. > sdeasey/ 224 15 months This commit was manufactured by > cvs2svn to create branch 'sdeasey'. > > What is all this upper/lowercase thing? > I thought we have something like: > > naviserver > modules > > BTW, in CVS, there are lot of "man" files imported at the > top of the tree. Those should be removed, I think. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2006-09-20 15:42:34
|
On 20.09.2006, at 17:30, Vlad Seryakov wrote:
> It is already available, i imported all branches and tags into SVN, go
> to SF and try browse Subversion. Once everybody agree, i will re-
> import
> most recent CVS version.
>
Hm
Rev. Age Author Last log entry
NAVISERVER/ 352 13 months This commit was manufactured by
cvs2svn to create branch 'NAVISERVER'.
NaviServer/ 1007 12 days This commit was manufactured by
cvs2svn to create branch 'NaviServer'.
Naviserver/ 870 2 months This commit was manufactured by
cvs2svn to create branch 'Naviserver'.
initial/ 3 19 months This commit was manufactured by cvs2svn
to create branch 'initial'.
nspostgres/ 228 15 months This commit was manufactured by
cvs2svn to create branch 'nspostgres'.
sdeasey/ 224 15 months This commit was manufactured by
cvs2svn to create branch 'sdeasey'.
What is all this upper/lowercase thing?
I thought we have something like:
naviserver
modules
BTW, in CVS, there are lot of "man" files imported at the
top of the tree. Those should be removed, I think.
|
|
From: Vlad S. <vl...@cr...> - 2006-09-20 15:30:39
|
It is already available, i imported all branches and tags into SVN, go to SF and try browse Subversion. Once everybody agree, i will re-import most recent CVS version. Zoran Vasiljevic wrote: > On 20.09.2006, at 17:17, Vlad Seryakov wrote: > >> Yes, subversion is open-source and available for all platforms. >> >> http://subversion.tigris.org/ > > OK. So what about the log history from CVS? > I guess there is some kind of magic export/import > that would move all to subversion? > The SF also supports subversion (I guess yes). > > Provided we all agree (count me in) > when/how you plan to do it? > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2006-09-20 15:25:00
|
On 20.09.2006, at 17:17, Vlad Seryakov wrote: > Yes, subversion is open-source and available for all platforms. > > http://subversion.tigris.org/ OK. So what about the log history from CVS? I guess there is some kind of magic export/import that would move all to subversion? The SF also supports subversion (I guess yes). Provided we all agree (count me in) when/how you plan to do it? |
|
From: Vlad S. <vl...@cr...> - 2006-09-20 15:17:49
|
Yes, subversion is open-source and available for all platforms. http://subversion.tigris.org/ Zoran Vasiljevic wrote: > On 20.09.2006, at 16:31, Vlad Seryakov wrote: > >> Nothing new, old commands are the same: >> >> cvs commit --- svn commit >> cvs update --- svn update >> >> New things like: >> >> svn mv >> svn rm >> .... > > I guess I would need to install new software. > Is there some ugly license attached that will > hunt me later on, as we are commercial company? > I'd need following platforms: > > Solaris 2.6+ (SPARC), Solaris x86 (Intel) > Mac OSX 10.2 (PPC) Mac OSX 10.4+ (Intel) > Linux (SuSE 8.1) > > those are my development platforms and that > SW should run there (as CVS does). > In future I'd need AIX 5 and HP/UX 11 in addition > to this list. What about that? > > Background: is SVN open-source? Can any/everybody > compile it, as CVS? > > > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2006-09-20 15:08:49
|
On 20.09.2006, at 16:31, Vlad Seryakov wrote: > Nothing new, old commands are the same: > > cvs commit --- svn commit > cvs update --- svn update > > New things like: > > svn mv > svn rm > .... I guess I would need to install new software. Is there some ugly license attached that will hunt me later on, as we are commercial company? I'd need following platforms: Solaris 2.6+ (SPARC), Solaris x86 (Intel) Mac OSX 10.2 (PPC) Mac OSX 10.4+ (Intel) Linux (SuSE 8.1) those are my development platforms and that SW should run there (as CVS does). In future I'd need AIX 5 and HP/UX 11 in addition to this list. What about that? Background: is SVN open-source? Can any/everybody compile it, as CVS? |
|
From: Vlad S. <vl...@cr...> - 2006-09-20 14:31:40
|
Nothing new, old commands are the same: cvs commit --- svn commit cvs update --- svn update New things like: svn mv svn rm .... Basically, easier file/directory manipulation also, it caches svn password, so no need to enter it every time:-))) Zoran Vasiljevic wrote: > On 20.09.2006, at 15:50, Vlad Seryakov wrote: > >> What do you think about migrating to SVN? >> > > What (mew) do I have to learn? How is this going > to benefit me or the project? > > Not that I'm lazy to learn new things. I just have > very little time, if this is not something that > considerably adds value. > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2006-09-20 14:25:20
|
On 20.09.2006, at 15:50, Vlad Seryakov wrote: > > What do you think about migrating to SVN? > What (mew) do I have to learn? How is this going to benefit me or the project? Not that I'm lazy to learn new things. I just have very little time, if this is not something that considerably adds value. |
|
From: Vlad S. <vl...@cr...> - 2006-09-20 13:51:10
|
Zoran, Stephen, What do you think about migrating to SVN? Vlad Seryakov wrote: > I converted and loaded current CVS HEAD into naviserver SVN repository, > CVS is still primary but we can play with SVN and decide to switch or > keep CVS. Personally, i switched to SVN more than a year ago in all my > projects and very happy with it, much better than CVS, especially with > directory and files handling. Of course i almost all the time work with > HEAD so i am the simplest case. > > > Migrating process may take some time, so i think tomorrow SVN repo will > be ready to use. > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2006-09-20 12:12:21
|
On 20.09.2006, at 13:36, Gustaf Neumann wrote: > > just my 2 cents... Very valuable insights from (obvious) experience ... Look at for example our case... We have 3 people VERY good at C and "low-level" programming (including kernel-level drivers). We have one guy pretty experienced in Web GUI development. We need to have at least one or two more in that area. So, basically, good knowledge of HTML, XML and CSS are absolute prerequisites. But, we need to create server-side pages. That is, you need to add the Tcl, as there is nothing in Naviserver that you can use instead. Mostly, people having written some "home-page"-kind of apps (if you can call this application at all) HAVE some experience in Javascript. Because more and more functionality will be done in JS (client-side) you need to have those people learn JS pretty good and this is what they will do. Now, why not piggybacking on that and give them the tools to employ their knowledge on the server-side as well? They need not write async code nor concurrent MT-code. For that we have libraries either in Tcl or (mostly) in C written by a. people (see below). In the near future, most of the Web-applications will be even more (heavily) based on JS then they are now. So people will invest more and more in that area. Why not take advantage of that? I believe one thing that we've isolated so far is: a. To write serves-side code (libraries, complex logic, etc) we will mostly stay with Tcl and C as I know this is unbeatable combination. Years and years of experience have thought me so. b. To write dynamic HTML pages to produce a client-based "application" will (always) be the case of mixing HTML/CSS/JS hence by using JS both server and client side simplifies the task of the programmer. He/she, after all, has already enough to do in order to mix JS with HTML/CSS. Adding something else (Tcl, PHP, whatever) was out of the necessity (historical reasons) and not out of the design reasons. To find people doing a. is very hard. But when you find them, then the language question is secondary. They already have enough experience to learn and be productive quickly given XYZ tool. This is NOT the audience I'm talking about. To find people doing b. is simpler. But as they do NOT have that extensive programming background, you can't expect from them to learn 4 different languages (HTML/CSS/JS/TCL) to write a web-based application. Even HTML/CSS/JS is pretty enough for them. By having the server-side pendant of JS just simplifies things for b. people. So, it is the b. I'm talking about. I'd like to make the burden of working with NS lower by adding alternative language to compose dynamic pages. |
|
From: Gustaf N. <ne...@wu...> - 2006-09-20 11:37:04
|
>> things from ground up. Learning time for Tcl isn't that long >> but then you get average (or less) code from the newbies. It is >> much better a person is already fluent in some language you use. >> He has less new things to learn. >> > > That's nice when it happens, but I think it's highly overrated. What > you typically want in a general programming hire is not so much > someone who has less to learn, as someone who habitually learns many > new things quickly. > While I fully agree with Andrew (hey, you are doing as well some R-programming!), I understand Zoran's situation as well. We have hired in the last half year 5 people with the skill set Tcl+aolserver+OpenACS/.LRN+XOTcl. But maybe it was easier for us, since due the the later mentioned constraints of the skill set, we did not really expect to hire someone who is ready to be productive from the first day. In other respects it is harder for us, since as a government institution we are not able to pay competitive salaries. For these positions, we had about 70 applications. I am somewhat happy that we did not mention JavaScript or PHP in our ads. We had a large group of applicants writing "programming skills in PHP, HTML and XML" or the like. From such sentences it is pretty easy to deduce what to expect (... "i have programmed my homepage." ..). There are many people out there with a very shallow idea of what programming is, and not really willing to involve themselves deeply with unknown problems. This are exactly the people, i do not want to hire. I expect from people primarily that they are willing to learn, willing to develop himself. Then, they should know a couple of languages (a few script languages, C, Java) and understand to use the right language for the right job. And, they should have programmed a significant piece of code by themselves and in a team. Many JavaScript users use JavaScript in a very shallow way. In my experience people with profound JavaScript knowledge are as rare as Tcl people. What puzzles me somewhat is the question, for what purposes one would like JavaScript in the aolserver. Using it for traditional scripting is fine (the real issues are here not programming but browser semantics for cross browser functionality). For "real programming" issues, hmm.... Ask applicants about the object model of JavaScript. I have done lately some JavaScript programming for web2-style applications (e.g. JavaScript based chat without polling). This was the first time when i really wished that the Netscape people should have chosen Tcl instead of JavaScript as a scripting language. JavaScript has no io and relies on the io semantics of the browser. Getting simple things like asynchronous io working cross-browser was and is a challenge. How easy would that be based on Tcl (or Perl, etc.)! One might argue that this is no the fault of JavaScript, since it is not part of the language. But it is part of e.g. Tcl. So, if one wants to write real applications, one has to leave the language and roll the own interfaces, etc. This should be done by people, knowing only JavaScript? In the mentioned project, i had as well situations, where the same pure JavaScript-code lead to different results on two different JavaScript implementations (length of the list differed by 1). Other issues (unknown to me) are: c-language interfaces (Tcl is here hard to beat), thread-safety, character encodings, introspection, code-reusability (having the need to program some stuff twice, once in Tcl, once in js), maintenance costs, libraries.... just my 2 cents... -gustaf neumann |
|
From: Zoran V. <zv...@ar...> - 2006-09-20 11:32:28
|
On 20.09.2006, at 12:17, Andrew Piskorski wrote: > On Wed, Sep 20, 2006 at 09:23:35AM +0200, Zoran Vasiljevic wrote: >> Well, if you have 10 contendents for the job and 10 of them >> know PHP and JS and NOBODY knows Tcl and you just spend 5K >> Euros for ads, you would think different... > > Why is that a problem? Are candidates losing interest in your company > because of some sort of stigma associated with Tcl? If so that could > be bad, but it doesn't sound like that's the problem. Candidates have mostly no problem with that. It is us. > > Zoran, since you've been a Tcl expert for so long, maybe you've > forgotten that learning Tcl is EASY? It is, you know, at least for > anybody good. (Or at least, I've both heard and seen many examples > and claims supporting that assertion, and have neither seen nor heard > of even a single contrary example or claim.) > Hm... easy... It is much better having somebody good in a tool and then you get good results. If you have to learn the tool then you're not fast in producing good results. You have a "experience-gathering-curve" which can be quite long(er). We need production-quality code and if you are new in something, then what you produce is mostly not comparable to somebody who is mastering the tool. But you know all this... > > Now, learning AOLserver and all your in-house APIs is probably much > more work than learning Tcl, but, any new hire is going to be starting > from scratch there anyway. Seriously, just how much extra time is > learning Tcl going to add to the time it takes for a JavaScript wizard > to become productive at your company? Maybe a week, three at the very > most? Why is that a real problem? Oh no... I'm speaking about a year to two-year=B4s time. Because this is IMHO what you need to feel fully comfortable with the tool and have hit all the "walls" you are supposed to hit. > > Hell, you Europeans take lots more vacation time than that every > single year. ;) > Perhaps, but you can't generalize :-) Last time I took vacation (that is, more that 3 working days off) was about 7 years ago :-/ > How long does your average programmer stay with your comany, years? > If so, and if you truly believe that your mostly Tcl environment is > highly productive for you, then you will easily recover that lost 1-3 > weeks in increased productivity later on, no problem. I cant say. All guys that started 7 years ago are still here. =46rom the previous company, it was about 3-5 years on average. But it is really not 1-3 weeks. It is rather 1-2 years. > >> It's just that we need new people and they need to be pretty >> quickly productive. We have no time to teach them all the > > It may sound trite, but then my advice is: Do your very best to hire > only people you KNOW have a proven history of being highly productive, > learning fast, and being self starting. (If you're company is small, > then that might be feasible simply through personal contacts. But I > guess not in your case.) It is difficult to find people. It is very difficult to find good people. If we had the chance to get to know "only people who have a proven history of being highly productive learning fast, and being self starting" we'd employ them ASAP. Yesterday. But we must take what we get. And that what we get are mostly Java, PHP and Javascript'ers. > > That's nice when it happens, but I think it's highly overrated. What > you typically want in a general programming hire is not so much > someone who has less to learn, as someone who habitually learns many > new things quickly. Hm... there is some truth in that, I admit. As said, to learn and understand something is one thing. To be _productive_ is another. For example: riding a bicycle can be learned fast (is the matter of hour or two). But to be the bicycle professional, you need years. |
|
From: Andrew P. <at...@pi...> - 2006-09-20 10:17:04
|
On Wed, Sep 20, 2006 at 09:23:35AM +0200, Zoran Vasiljevic wrote: > Well, if you have 10 contendents for the job and 10 of them > know PHP and JS and NOBODY knows Tcl and you just spend 5K > Euros for ads, you would think different... Why is that a problem? Are candidates losing interest in your company because of some sort of stigma associated with Tcl? If so that could be bad, but it doesn't sound like that's the problem. Zoran, since you've been a Tcl expert for so long, maybe you've forgotten that learning Tcl is EASY? It is, you know, at least for anybody good. (Or at least, I've both heard and seen many examples and claims supporting that assertion, and have neither seen nor heard of even a single contrary example or claim.) Yes, I'm basically just repeating an old Greenspun mantra here, but I'm repeating it because AFAICT it's true. [scratches head] Really, back when I did the three week ArsDigita Boot Camp in early 2000, I saw some people whom I DIDN'T consider sharp enough to hire as programmers pick up Tcl quickly, including at least one person who didn't have even a glimmer of programming experience at all, zip zero nada, (and in fact little computer experience period, didn't even know to type "ls" at the Unix shell prompt...) And Tcl definitely does have a real advantage in ease and speed of learning AFAICT. E.g., I also like the R programaming langauge a lot (despite some ugly corners), and R is also a high level, dynamic, rapid development language, but it took me quite a lot longer to come up to speed with R than it did with Tcl, and I'd had MUCH more programming experience by that time... Now, learning AOLserver and all your in-house APIs is probably much more work than learning Tcl, but, any new hire is going to be starting from scratch there anyway. Seriously, just how much extra time is learning Tcl going to add to the time it takes for a JavaScript wizard to become productive at your company? Maybe a week, three at the very most? Why is that a real problem? Hell, you Europeans take lots more vacation time than that every single year. ;) How long does your average programmer stay with your comany, years? If so, and if you truly believe that your mostly Tcl environment is highly productive for you, then you will easily recover that lost 1-3 weeks in increased productivity later on, no problem. > It's just that we need new people and they need to be pretty > quickly productive. We have no time to teach them all the It may sound trite, but then my advice is: Do your very best to hire only people you KNOW have a proven history of being highly productive, learning fast, and being self starting. (If you're company is small, then that might be feasible simply through personal contacts. But I guess not in your case.) > things from ground up. Learning time for Tcl isn't that long > but then you get average (or less) code from the newbies. It is > much better a person is already fluent in some language you use. > He has less new things to learn. That's nice when it happens, but I think it's highly overrated. What you typically want in a general programming hire is not so much someone who has less to learn, as someone who habitually learns many new things quickly. -- Andrew Piskorski <at...@pi...> http://www.piskorski.com/ |
|
From: Zoran V. <zv...@ar...> - 2006-09-20 07:23:46
|
On 20.09.2006, at 00:04, Andrew Piskorski wrote: > On Tue, Sep 19, 2006 at 07:05:18PM +0200, Zoran Vasiljevic wrote: > >> Don't worry. I will not start turning things arround for >> integration of the JS into NaviServer. But I will have to >> find a mid/long term solution for this. > > Solution to what? What problem? Problem finding people and get them immediately (i.e. as soon as possible) productive when working on our product (based on NS). > >> We are now a bunch of Tcl freaks (by "we" I mean people in my >> company) and we have pretty much under control. >> But if/when we get somebody new on the board, it is more than >> certain that he/she knows either PHP or Javascript or both, >> to a leeser extent the rest of the scripting languages with >> Tcl being pretty much towards the tail of the list. >> >> In order to make this person immediately productive, a kind-of >> "well-known" environment is from benefit. > > IMNSHO that's silly and probably asking for trouble. If your company > HIRES someone that person is going to have to learn the programming > languages that are standard and widespread in your company (e.g., > Tcl), end of story. If the fact that this new hire "already knows" > PHP or JavaScript is somehow important, you probably hired the wrong > person. Well, if you have 10 contendents for the job and 10 of them know PHP and JS and NOBODY knows Tcl and you just spend 5K Euros for ads, you would think different... > > Zoran, if you have contrary experiences or intuition I'm interested in > hearing it, but Yes, Above... > IMO, the only cases where it makes sense for a new > hire at a small company to program in a new and different language, > are the cases where YOU would have wanted to adopt that language > anyway, but simply hadn't had the time or expertise to get around to > it yet. (E.g., you believe that language X would be more appropriate > for some new project, and lo and behold, the new guy happens to > already be an X expert, let's stick him on the new project.) It's just that we need new people and they need to be pretty quickly productive. We have no time to teach them all the things from ground up. Learning time for Tcl isn't that long but then you get average (or less) code from the newbies. It is much better a person is already fluent in some language you use. He has less new things to learn. > > Adding JavaScript to NaviServer sounds like a fairly cool project, and > would certainly make a nice hack for your own entertainment or > edification. But, as a production worthy tool, I'd guess that sinking > time into it is probably a mistake unless you have a clear customer > for it. No customer. Our customers don't know (and don't care) what we use from tools to make the job done. As you are (mostly) not caring what type of clutch or pistons are in your car, as long as it drives. It is the potential collegues who need to continue (or perhaps take over) what we have done until now. I must prepare for this step. > > In other words, do you have some good reason to really use it > seriously at your own company? Yes. > Or are you being paid to provide this > tool to someone else who does? No. > If so, awesome! But if not, well, if > I were in your shoes I'd skip it. Except, note, for the entertainment > or self-education cases I mentioned above. (A cool hack is always a > good thing, especially as there's always the small chance that someone > else will pick it up and run with it.) > > Personally, my position to any new hire would be (and has been): > If using some entirely different programming language or other tool > will be particularly valuable in solving the problem, awesome, use it. > (And I am curious about this language, teach me more about it please!) > But if the new language does not have some special advantage in the > problem domain over the languages we already use, then please stick to > the ones we already use, wherever practical. "wherever practical". Well JS will certainly bring nothing new or more "cool" to what we have now. But would allow easier adaption for a newbie. > > That initial rule of thumb will then in practice leads to further > derived guidelines, e.g.: No, where possible please don't write > misc. utility scripts in Perl or Python, as that's the same problem > domain served by Tcl, and we are already very heavy Tcl users. No, > unless you have some other good reason, please don't write your > misc. math and statistical code in Matlab, as we use R for that. Etc. > > There are of course many, many other application domains, programming > paradigms, and good tools to serve them which I've never used before > at all. (Perhaps including Erlang, Prolog, Mozart/Oz, Scheme, E, or > even APL.) But unless I'm missing something, adding server-side > JavaScript to NaviServer isn't really one of those, it's just a > different flavor of the same NaviServer/Tcl stuff we've had all along. Yes. This is exactly true. It would not add anything new. Rather, it would be, most probably, even less functional! It would however lower the acceptance barrier, as people would have _less_ to learn. But, rest assure... I will not dive into that this very moment! There are other (more important) things to do at this point of time. Still, some day or another, I will have to start working on that. BTW, I was thinking about PHP but I've abandon it because of the thread-safety issues (first) and ugliness (second) of the produced code. JS seemes like a good candidate for me. You know, even my girlfriend (she's doing some web-design in her spare time) started to learn JS. This gave me a hint... |
|
From: Andrew P. <at...@pi...> - 2006-09-19 22:04:37
|
On Tue, Sep 19, 2006 at 07:05:18PM +0200, Zoran Vasiljevic wrote: > Don't worry. I will not start turning things arround for > integration of the JS into NaviServer. But I will have to > find a mid/long term solution for this. Solution to what? What problem? > We are now a bunch of Tcl freaks (by "we" I mean people in my > company) and we have pretty much under control. > But if/when we get somebody new on the board, it is more than > certain that he/she knows either PHP or Javascript or both, > to a leeser extent the rest of the scripting languages with > Tcl being pretty much towards the tail of the list. > > In order to make this person immediately productive, a kind-of > "well-known" environment is from benefit. IMNSHO that's silly and probably asking for trouble. If your company HIRES someone that person is going to have to learn the programming languages that are standard and widespread in your company (e.g., Tcl), end of story. If the fact that this new hire "already knows" PHP or JavaScript is somehow important, you probably hired the wrong person. Zoran, if you have contrary experiences or intuition I'm interested in hearing it, but IMO, the only cases where it makes sense for a new hire at a small company to program in a new and different language, are the cases where YOU would have wanted to adopt that language anyway, but simply hadn't had the time or expertise to get around to it yet. (E.g., you believe that language X would be more appropriate for some new project, and lo and behold, the new guy happens to already be an X expert, let's stick him on the new project.) Adding JavaScript to NaviServer sounds like a fairly cool project, and would certainly make a nice hack for your own entertainment or edification. But, as a production worthy tool, I'd guess that sinking time into it is probably a mistake unless you have a clear customer for it. In other words, do you have some good reason to really use it seriously at your own company? Or are you being paid to provide this tool to someone else who does? If so, awesome! But if not, well, if I were in your shoes I'd skip it. Except, note, for the entertainment or self-education cases I mentioned above. (A cool hack is always a good thing, especially as there's always the small chance that someone else will pick it up and run with it.) Personally, my position to any new hire would be (and has been): If using some entirely different programming language or other tool will be particularly valuable in solving the problem, awesome, use it. (And I am curious about this language, teach me more about it please!) But if the new language does not have some special advantage in the problem domain over the languages we already use, then please stick to the ones we already use, wherever practical. That initial rule of thumb will then in practice leads to further derived guidelines, e.g.: No, where possible please don't write misc. utility scripts in Perl or Python, as that's the same problem domain served by Tcl, and we are already very heavy Tcl users. No, unless you have some other good reason, please don't write your misc. math and statistical code in Matlab, as we use R for that. Etc. There are of course many, many other application domains, programming paradigms, and good tools to serve them which I've never used before at all. (Perhaps including Erlang, Prolog, Mozart/Oz, Scheme, E, or even APL.) But unless I'm missing something, adding server-side JavaScript to NaviServer isn't really one of those, it's just a different flavor of the same NaviServer/Tcl stuff we've had all along. -- Andrew Piskorski <at...@pi...> http://www.piskorski.com/ |
|
From: Zoran V. <zv...@ar...> - 2006-09-19 17:05:25
|
On 17.09.2006, at 20:44, Mike wrote: > Vote: -1 > Explanation: waste of time Allirght. Although I would not strictly categorize this as waste of time... We are now a bunch of Tcl freaks (by "we" I mean people in my company) and we have pretty much under control. But if/when we get somebody new on the board, it is more than certain that he/she knows either PHP or Javascript or both, to a leeser extent the rest of the scripting languages with Tcl being pretty much towards the tail of the list. In order to make this person immediately productive, a kind-of "well-known" environment is from benefit. Don't worry. I will not start turning things arround for integration of the JS into NaviServer. But I will have to find a mid/long term solution for this. Cheers Zoran |
|
From: Zoran V. <zv...@ar...> - 2006-09-19 14:59:39
|
On 19.09.2006, at 15:42, Zoran Vasiljevic wrote: > But Stephen has confused me with his last email about problems > in "eval" command, which I can't see. > Actually we do not need the "eval" at all! It is sufficient to: ns_job queue ns_job wait and whoever wants a "eval" can couple those two with a tiny Tcl procedure. Even in the current proxy, the eval is nothing but a sequence of send wait recv (it is really implemented so down below). |
|
From: Zoran V. <zv...@ar...> - 2006-09-19 13:42:26
|
On 19.09.2006, at 15:32, Vlad Seryakov wrote: > I like the idea of extending ns_job to handle processes, this way > when i > create queue i define what kind it is: threads or processes and > then use > it same way, no need in eval command, ns_job queue submites script > to be > evaluated to the next avail thread/process Yes. This what I also thought after seeing the similarities between the two. Normally you should create a thread or process queue and after that, it should be pretty generic i.e. the API would hide the rest from you. But Stephen has confused me with his last email about problems in "eval" command, which I can't see. |
14 messages has been excluded from this view by a project administrator.
