Menu
▾
▴
octave-dev — GNU Octave developers' list
This list is closed, nobody may subscribe to it.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(14) |
Nov
(10) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
(4) |
Mar
|
Apr
(3) |
May
(13) |
Jun
(2) |
Jul
(7) |
Aug
|
Sep
(2) |
Oct
(5) |
Nov
(8) |
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
(19) |
Apr
(8) |
May
(8) |
Jun
(8) |
Jul
(4) |
Aug
(8) |
Sep
(19) |
Oct
(13) |
Nov
(37) |
Dec
(2) |
| 2003 |
Jan
(7) |
Feb
(23) |
Mar
(16) |
Apr
(4) |
May
(18) |
Jun
(9) |
Jul
(7) |
Aug
(6) |
Sep
(7) |
Oct
|
Nov
(39) |
Dec
(57) |
| 2004 |
Jan
(21) |
Feb
(15) |
Mar
(17) |
Apr
(9) |
May
(17) |
Jun
(65) |
Jul
(33) |
Aug
(48) |
Sep
(93) |
Oct
(35) |
Nov
(18) |
Dec
(4) |
| 2005 |
Jan
(20) |
Feb
(59) |
Mar
(17) |
Apr
(59) |
May
(77) |
Jun
(32) |
Jul
(34) |
Aug
(8) |
Sep
(34) |
Oct
(26) |
Nov
(65) |
Dec
(66) |
| 2006 |
Jan
(45) |
Feb
(37) |
Mar
(50) |
Apr
(32) |
May
(48) |
Jun
(42) |
Jul
(12) |
Aug
(53) |
Sep
(51) |
Oct
(79) |
Nov
(46) |
Dec
(25) |
| 2007 |
Jan
(120) |
Feb
(78) |
Mar
(45) |
Apr
(91) |
May
(155) |
Jun
(66) |
Jul
(96) |
Aug
(110) |
Sep
(145) |
Oct
(189) |
Nov
(68) |
Dec
(160) |
| 2008 |
Jan
(163) |
Feb
(212) |
Mar
(209) |
Apr
(157) |
May
(216) |
Jun
(120) |
Jul
(80) |
Aug
(83) |
Sep
(98) |
Oct
(120) |
Nov
(80) |
Dec
(129) |
| 2009 |
Jan
(45) |
Feb
(80) |
Mar
(174) |
Apr
(142) |
May
(133) |
Jun
(191) |
Jul
(183) |
Aug
(138) |
Sep
(77) |
Oct
(141) |
Nov
(209) |
Dec
(131) |
| 2010 |
Jan
(85) |
Feb
(213) |
Mar
(245) |
Apr
(222) |
May
(168) |
Jun
(82) |
Jul
(50) |
Aug
(144) |
Sep
(92) |
Oct
(80) |
Nov
(64) |
Dec
(78) |
| 2011 |
Jan
(58) |
Feb
(98) |
Mar
(112) |
Apr
(98) |
May
(64) |
Jun
(150) |
Jul
(126) |
Aug
(59) |
Sep
(271) |
Oct
(154) |
Nov
(321) |
Dec
(183) |
| 2012 |
Jan
(146) |
Feb
(217) |
Mar
(426) |
Apr
(208) |
May
(206) |
Jun
(230) |
Jul
(158) |
Aug
(170) |
Sep
(237) |
Oct
(260) |
Nov
(178) |
Dec
|
|
From: JuanPi <aj...@gm...> - 2012-09-26 10:54:15
|
Hi, I received a oral request to make "pkg update" keep the autoload configuration define by the user. Apparently currently it doesn't. Also to make it accept a list of package to update. I added this to the wiki. -- JuanPi Carbajal ----- "It is one thing not to be able to perform a certain feat, but quite another to prove that it cannot be done." - Henry Ernest Dudeney ----- http://ailab.ifi.uzh.ch/carbajal/ |
|
From: Carnë D. <car...@gm...> - 2012-09-26 10:10:33
|
On 26 September 2012 11:18, adam aitkenhead <ada...@ho...> wrote: >> Date: Tue, 25 Sep 2012 22:45:34 +0100 >> Subject: Re: [OctDev] Dicom package / isdicom function: Carnë, please read >> From: and...@gm... >> To: car...@gm... >> CC: ada...@ho...; oct...@li... >> >> >> Carnë - can Adam get write permission for the svn repo? He has work to >> >> do (see below ;) >> >> >> >> Adam - do you have a sf.net account? Could you get a checkout and >> >> commit a fix? > > Yup, I'm on sourceforge - adam78a Done. You should have commit access now. Carnë |
|
From: Carnë D. <car...@gm...> - 2012-09-26 10:06:50
|
On 26 September 2012 11:10, adam aitkenhead <ada...@ho...> wrote: >> From: car...@gm... >> Date: Tue, 25 Sep 2012 19:34:15 +0200 >> Subject: Re: [OctDev] Analyze75 >> To: ada...@ho... >> CC: oct...@li... >> >> hey, please avoid top posting. Reply at the bottom >> >> On 25 September 2012 17:07, adam aitkenhead <ada...@ho...> >> wrote: >> >> From: car...@gm... >> >> Date: Tue, 25 Sep 2012 16:30:48 +0200 >> > >> >> Another thing I noticed is the many ways it tries to handle invalid >> >> filenames. While it looks kinda slick, I'm not sure it's a good idea >> >> to have the function doing it, it should be done by the script that >> >> calls it. When you give wrong arguments to a function, trying to guess >> >> what is right can lead to weird results. Or does matlab also behaves >> >> that way (it's not documented at least). My suggestion would be to >> >> maybe display the file selection if no argument is given but return an >> >> error if the filenames are not valid files. What do you think? >> >> >> > >> > All sounds good to me. Makes sense to keep to the standard way of doing >> > things to make it behave as others might expect. I'm not all that >> > familiar >> > with the standard (yet), so if you see any ways to standardise it that >> > is >> > great. >> >> I've made a few more changes. Could you please give them a try to make >> sure I didn't broke anything? :p >> >> I've moved the code that was common between read and info into a >> shared private function, checks after fseek and fopen, everything in >> one function (I see no need to have subfunctions since they are only >> called once anyway), replaced a long if block for a switch block, >> changed many checks for simpler, used dir to check the file size >> (rather than the low level fseek and ftell), and a lot of whitespace >> to make it pretty and extended documentation. I tried to make the code >> run in matlab (though I'd guess a matlab user would actually just use >> the matlab function). >> >> Here's the files: >> >> https://sourceforge.net/p/octave/code/11114/tree//trunk/octave-forge/main/image/inst/private/analyze75filename.m >> >> https://sourceforge.net/p/octave/code/11114/tree//trunk/octave-forge/main/image/inst/analyze75info.m >> >> https://sourceforge.net/p/octave/code/11114/tree//trunk/octave-forge/main/image/inst/analyze75read.m >> >> > About the input checks - I'd aimed to make it behave as Matlab does for >> > all >> > acceptable inputs. But for the cases where Matlab throws an error, this >> > function generally asks the user what to do instead. But I'm happy for >> > this >> > to be simplified or left for other functions which call these. >> >> Done. >> >> Carnë > > Changes look good. Few minor edits to analyze75filename.m (see below), but > otherwise everything works well. Thanks for the help tidying it up! > > - function filename = analyze75check (filename) > + function filename = analyze75filename (filename) > > - elseif (~exist (filename,'file') > + elseif (~exist (filename,'file')) > > - error ('analyze75info: no file `%s''', filename) > + error ('analyze75: no file `%s''', filename) Thanks. Fixed |
|
From: adam a. <ada...@ho...> - 2012-09-26 09:18:51
|
> Date: Tue, 25 Sep 2012 22:45:34 +0100 > Subject: Re: [OctDev] Dicom package / isdicom function: Carnë, please read > From: and...@gm... > To: car...@gm... > CC: ada...@ho...; oct...@li... > > On 25 September 2012 20:40, Carnë Draug <car...@gm...> wrote: > > On 25 September 2012 21:23, Andy Buckle <and...@gm...> wrote: > >> On 19 September 2012 17:26, adam aitkenhead <ada...@ho...> wrote: > >>> > >>> Hi Andy, > >>> > >>> I've attached an updated version of the isdicom function which can now check > >>> a list of files (in a cell array) in one go, which is much quicker than > >>> checking each file separately. Again, no rush for releasing a new version > >>> of the toolbox - just some changes I was making for my own code anyway. > >>> > >>> Also on a different note, I've written functions which read/write the > >>> Analyze format, giving functions equivalent to Matlab's analyze75info and > >>> analyze75read. Would you rather keep the Dicom toolbox purely for the Dicom > >>> format, or are you interested in expanding it to become a general Medical > >>> File Format toolbox? No worries if not, just thought I'd see what you > >>> thought before I see where else they could fit into Octave-forge. > >>> > >>> Adam > >>> > >>>> Date: Thu, 13 Sep 2012 14:57:29 +0100 > >>> > >>>> Subject: Re: [OctDev] Dicom package / isdicom function > >>>> From: and...@gm... > >>>> To: ada...@ho... > >>>> > >>>> > I have access to Matlab too, and it recognises the non-standard DICOM > >>>> > file. > >>>> > (Just to note, although I have tested the ML behaviour for a some test > >>>> > files, I didn't use Matlab as a basis for the code.) > >>>> > >>>> Excellent. That is the way to do it. We are careful about copyright. > >>>> > >>>> Andy > >> > >> Carnë - can Adam get write permission for the svn repo? He has work to > >> do (see below ;) > >> > >> Adam - do you have a sf.net account? Could you get a checkout and commit a fix? > >> > >> I have committed isdicom.m. I added a couple of tests. > > > > You didn't. Your last commit only changes makefile > > > > Carnë > > oops ... svn add ... tries again > > Thanks Carnë > -- > /* andy buckle */ Yup, I'm on sourceforge - adam78a |
|
From: Philip N. <pr....@hc...> - 2012-09-26 07:21:01
|
<[OtcDev] ML added too (I shouldn't have added help-octave)>
Please don't top post. Answer below the mail
Swift, Ted J. wrote:
> -----Original Message-----
> From: prn...@us... [mailto:prn...@us...]
> Sent: Thursday, September 13, 2012 1:41 AM
> To: Swift, Ted J.
> Subject: FWD: Re: [OctDev] xlread in 3.6.1
>
> <resent, reply to your personal e-mail bounced as that was shielded by Nabble>
>
> TedSwift [via Octave] wrote:
>>> I've followed this thread, but am still not able to get
>>> chk_spreadsheet_support to check out right. After putting Java in
>>> what I thought was the right place, these are the results of my last
>>> check:
>>>
>>> octave:5> chk_spreadsheet_support ('', 3)
>>>
>>> Checking Excel/ActiveX/COM... not working.
>>>
>>> Checking Java support...
>>> 1. Checking Java JRE presence.... OK, found one.
>>> 2. Checking Octave Java support... error: No Java support found:
>>> `java_invoke' undefined near line 49 column 16.
> => no or improperly installed Java package.
>
>>> error: called from:
>>> error:
>>> C:/Octave/Octave3.6.1_gcc4.6.2/share/octave/packages\io-1.0.18\chk_s
>>> preadsheet_support.m
>>> at line 176, column 3
>>>
>>> Something fundamental is still missing, or I don't have the setenv
>>> path set right. Are there any other diagnostic tools that will help
>>> me figure out where the breakdown is? Thanks, all.
> Try to run the newest Java package preinstall.m before your next attempt to install the Java package (any version).
> This file is in the svn repo here:
>
> http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/java/pre_install.m?sortby=rev&view=log
> (watch for line wrap, take revision 10760, "download" or "as text", be sure to save it as a .m-file, and run it in Octave)
>
> I've only recently committed it in an attempt to avoid half-baked Java package installations.
> It'll check where Octave should look for the jvm lib and the executables and will complain if any of them is not found.
>
> I think the fact that the Java package installer not being able to find the Java executables (java, jar, javac) in the place it expects them to be was the creepy showstopper in many frustrating cases.
> You might make symlinks to them in your $PATH (in my Mageia 2 linux installation they seem to be silently created in /usr/bin by urpmi).
>
> Please copy preinstall.m's error msg (if any) in a reply mail. For me that's handy to have, because I might decide to implement (parts of) preinstall.m's functionality in chk_spreadsheet_support as well.
>
> BTW I've also recently updated the Octave wiki on exactly this subject:
> http://wiki.octave.org/Java_package#Make_sure_that_the_build_environment_is_configured_properly
> (line wrap!)
>
> Philip,
> Thank you very much for the advice and pointers. And sorry for the
> delay in replying; I was busy last week being part of the
> organizing team for a scientific conference.
> Thanks for writing pre_install.m. I downloaded it and tried it,
> but it didn't provide any new insight: It did not return any errors.
> However, after I ran pre_install, I immediately ran
> chk_spreadsheet_support, and received the same error I've received
> before. Here's the transcript:
>
>> GNU Octave, version 3.6.1
<snip>
>> octave:1> pwd
>> ans = C:\Users\tswift
>> octave:2> run pre_install.m %<--------- NOTE: No
>> error returned
You should have just typed:
preinstall
and watch the output. No "run", no ".m" suffix. Just:
preinstall
Note: scripts and function files seem to run better if invoked with just
their file name w/o suffix.
Philip
|
|
From: Andy B. <and...@gm...> - 2012-09-25 21:45:41
|
On 25 September 2012 20:40, Carnë Draug <car...@gm...> wrote: > On 25 September 2012 21:23, Andy Buckle <and...@gm...> wrote: >> On 19 September 2012 17:26, adam aitkenhead <ada...@ho...> wrote: >>> >>> Hi Andy, >>> >>> I've attached an updated version of the isdicom function which can now check >>> a list of files (in a cell array) in one go, which is much quicker than >>> checking each file separately. Again, no rush for releasing a new version >>> of the toolbox - just some changes I was making for my own code anyway. >>> >>> Also on a different note, I've written functions which read/write the >>> Analyze format, giving functions equivalent to Matlab's analyze75info and >>> analyze75read. Would you rather keep the Dicom toolbox purely for the Dicom >>> format, or are you interested in expanding it to become a general Medical >>> File Format toolbox? No worries if not, just thought I'd see what you >>> thought before I see where else they could fit into Octave-forge. >>> >>> Adam >>> >>>> Date: Thu, 13 Sep 2012 14:57:29 +0100 >>> >>>> Subject: Re: [OctDev] Dicom package / isdicom function >>>> From: and...@gm... >>>> To: ada...@ho... >>>> >>>> > I have access to Matlab too, and it recognises the non-standard DICOM >>>> > file. >>>> > (Just to note, although I have tested the ML behaviour for a some test >>>> > files, I didn't use Matlab as a basis for the code.) >>>> >>>> Excellent. That is the way to do it. We are careful about copyright. >>>> >>>> Andy >> >> Carnë - can Adam get write permission for the svn repo? He has work to >> do (see below ;) >> >> Adam - do you have a sf.net account? Could you get a checkout and commit a fix? >> >> I have committed isdicom.m. I added a couple of tests. > > You didn't. Your last commit only changes makefile > > Carnë oops ... svn add ... tries again Thanks Carnë -- /* andy buckle */ |
|
From: Carnë D. <car...@gm...> - 2012-09-25 19:40:55
|
On 25 September 2012 21:23, Andy Buckle <and...@gm...> wrote: > On 19 September 2012 17:26, adam aitkenhead <ada...@ho...> wrote: >> >> Hi Andy, >> >> I've attached an updated version of the isdicom function which can now check >> a list of files (in a cell array) in one go, which is much quicker than >> checking each file separately. Again, no rush for releasing a new version >> of the toolbox - just some changes I was making for my own code anyway. >> >> Also on a different note, I've written functions which read/write the >> Analyze format, giving functions equivalent to Matlab's analyze75info and >> analyze75read. Would you rather keep the Dicom toolbox purely for the Dicom >> format, or are you interested in expanding it to become a general Medical >> File Format toolbox? No worries if not, just thought I'd see what you >> thought before I see where else they could fit into Octave-forge. >> >> Adam >> >>> Date: Thu, 13 Sep 2012 14:57:29 +0100 >> >>> Subject: Re: [OctDev] Dicom package / isdicom function >>> From: and...@gm... >>> To: ada...@ho... >>> >>> > I have access to Matlab too, and it recognises the non-standard DICOM >>> > file. >>> > (Just to note, although I have tested the ML behaviour for a some test >>> > files, I didn't use Matlab as a basis for the code.) >>> >>> Excellent. That is the way to do it. We are careful about copyright. >>> >>> Andy > > Carnë - can Adam get write permission for the svn repo? He has work to > do (see below ;) > > Adam - do you have a sf.net account? Could you get a checkout and commit a fix? > > I have committed isdicom.m. I added a couple of tests. You didn't. Your last commit only changes makefile Carnë |
|
From: Andy B. <and...@gm...> - 2012-09-25 19:23:20
|
On 19 September 2012 17:26, adam aitkenhead <ada...@ho...> wrote: > > Hi Andy, > > I've attached an updated version of the isdicom function which can now check > a list of files (in a cell array) in one go, which is much quicker than > checking each file separately. Again, no rush for releasing a new version > of the toolbox - just some changes I was making for my own code anyway. > > Also on a different note, I've written functions which read/write the > Analyze format, giving functions equivalent to Matlab's analyze75info and > analyze75read. Would you rather keep the Dicom toolbox purely for the Dicom > format, or are you interested in expanding it to become a general Medical > File Format toolbox? No worries if not, just thought I'd see what you > thought before I see where else they could fit into Octave-forge. > > Adam > >> Date: Thu, 13 Sep 2012 14:57:29 +0100 > >> Subject: Re: [OctDev] Dicom package / isdicom function >> From: and...@gm... >> To: ada...@ho... >> >> > I have access to Matlab too, and it recognises the non-standard DICOM >> > file. >> > (Just to note, although I have tested the ML behaviour for a some test >> > files, I didn't use Matlab as a basis for the code.) >> >> Excellent. That is the way to do it. We are careful about copyright. >> >> Andy Carnë - can Adam get write permission for the svn repo? He has work to do (see below ;) Adam - do you have a sf.net account? Could you get a checkout and commit a fix? I have committed isdicom.m. I added a couple of tests. It agrees with me that I have a DICOM file. When I throw non-dicom files at it, it grumbles. > isdicom ../dcm_examples/RD.15MV.DCM ans = 1 > isdicom dicomdict.h warning: fopen: file found in load path error: READ_dicom_dict: A(I): index out of bounds; value 1 out of bound 0 error: called from: error: /home/andy/octave-forge/extra/dicom/inst/isdicom.m at line 123, column 19 error: /home/andy/octave-forge/extra/dicom/inst/isdicom.m at line 72, column 14 -- /* andy buckle */ |
|
From: Carnë D. <car...@gm...> - 2012-09-25 17:34:43
|
hey, please avoid top posting. Reply at the bottom On 25 September 2012 17:07, adam aitkenhead <ada...@ho...> wrote: >> From: car...@gm... >> Date: Tue, 25 Sep 2012 16:30:48 +0200 > >> Another thing I noticed is the many ways it tries to handle invalid >> filenames. While it looks kinda slick, I'm not sure it's a good idea >> to have the function doing it, it should be done by the script that >> calls it. When you give wrong arguments to a function, trying to guess >> what is right can lead to weird results. Or does matlab also behaves >> that way (it's not documented at least). My suggestion would be to >> maybe display the file selection if no argument is given but return an >> error if the filenames are not valid files. What do you think? >> > > All sounds good to me. Makes sense to keep to the standard way of doing > things to make it behave as others might expect. I'm not all that familiar > with the standard (yet), so if you see any ways to standardise it that is > great. I've made a few more changes. Could you please give them a try to make sure I didn't broke anything? :p I've moved the code that was common between read and info into a shared private function, checks after fseek and fopen, everything in one function (I see no need to have subfunctions since they are only called once anyway), replaced a long if block for a switch block, changed many checks for simpler, used dir to check the file size (rather than the low level fseek and ftell), and a lot of whitespace to make it pretty and extended documentation. I tried to make the code run in matlab (though I'd guess a matlab user would actually just use the matlab function). Here's the files: https://sourceforge.net/p/octave/code/11114/tree//trunk/octave-forge/main/image/inst/private/analyze75filename.m https://sourceforge.net/p/octave/code/11114/tree//trunk/octave-forge/main/image/inst/analyze75info.m https://sourceforge.net/p/octave/code/11114/tree//trunk/octave-forge/main/image/inst/analyze75read.m > About the input checks - I'd aimed to make it behave as Matlab does for all > acceptable inputs. But for the cases where Matlab throws an error, this > function generally asks the user what to do instead. But I'm happy for this > to be simplified or left for other functions which call these. Done. Carnë |
|
From: adam a. <ada...@ho...> - 2012-09-25 15:07:45
|
All sounds good to me. Makes sense to keep to the standard way of doing things to make it behave as others might expect. I'm not all that familiar with the standard (yet), so if you see any ways to standardise it that is great. About the input checks - I'd aimed to make it behave as Matlab does for all acceptable inputs. But for the cases where Matlab throws an error, this function generally asks the user what to do instead. But I'm happy for this to be simplified or left for other functions which call these. > From: car...@gm... > Date: Tue, 25 Sep 2012 16:30:48 +0200 > Subject: Re: [OctDev] Analyze75 > To: ada...@ho... > CC: oct...@li... > > I've been changing a bit the input check. The standard we have is to > check the value of nargin. Doing this at the start means that you > don't have to check if the variable exists later. > > Another thing I noticed is the many ways it tries to handle invalid > filenames. While it looks kinda slick, I'm not sure it's a good idea > to have the function doing it, it should be done by the script that > calls it. When you give wrong arguments to a function, trying to guess > what is right can lead to weird results. Or does matlab also behaves > that way (it's not documented at least). My suggestion would be to > maybe display the file selection if no argument is given but return an > error if the filenames are not valid files. What do you think? > > Carnë |
|
From: Carnë D. <car...@gm...> - 2012-09-25 14:31:16
|
On 25 September 2012 15:11, adam aitkenhead <ada...@ho...> wrote: > Thanks for the tips, they all sound like a good idea - I'll aim to follow > them for future code. (Yup, I've been trying to keep the code so that it > also works in Matlab where possible.) I've been changing a bit the input check. The standard we have is to check the value of nargin. Doing this at the start means that you don't have to check if the variable exists later. Another thing I noticed is the many ways it tries to handle invalid filenames. While it looks kinda slick, I'm not sure it's a good idea to have the function doing it, it should be done by the script that calls it. When you give wrong arguments to a function, trying to guess what is right can lead to weird results. Or does matlab also behaves that way (it's not documented at least). My suggestion would be to maybe display the file selection if no argument is given but return an error if the filenames are not valid files. What do you think? Carnë |
|
From: adam a. <ada...@ho...> - 2012-09-25 13:11:36
|
Hi Carnë Thanks for the tips, they all sound like a good idea - I'll aim to follow them for future code. (Yup, I've been trying to keep the code so that it also works in Matlab where possible.) When you're ready with everything else just go ahead and release the package, I can't guarantee I'll be able to tidy up the remaining function quickly so I don't want to hold things up. This email address is fine, thanks for adding it. Thanks, Adam > From: car...@gm... > Date: Tue, 25 Sep 2012 14:51:42 +0200 > Subject: Re: [OctDev] Analyze75 > To: ada...@ho... > CC: oct...@li... > > On 25 September 2012 11:17, adam aitkenhead <ada...@ho...> wrote: > > Hi Carnë, > > > > Attached are those m files for analyze75info and analyze75read - I've > > reformatted them to use Matlab's syntax. I've still to tidy up > > analyze75write, but I'll send it on later this week if I can. > > > > Adam > > Hi Adam > > Thank you for the functions. I have just made the commit and added > them to the package. I have added your e-mail to the copyright notice > but let me know if you have another address that you prefer. I can > wait a bit more to have the whole analyze75 set of functions. > > If you are already tidying up the next function, would be cool if you > could follow some of the standards of Octave core (most in Octave > Forge don't follow it but I find they good standards). Here's some: > > * indent the function body (this will save from writing end %function) > * spaces after function names > * no spaces after variables for indexing > * user @var for variables name in the help text (do not capitalize them) > > I'd suggest the others but it seems to me that you want to keep your > code Matlab compatible. Is that correct? > > Carnë |
|
From: Carnë D. <car...@gm...> - 2012-09-25 12:52:13
|
On 25 September 2012 11:17, adam aitkenhead <ada...@ho...> wrote: > Hi Carnë, > > Attached are those m files for analyze75info and analyze75read - I've > reformatted them to use Matlab's syntax. I've still to tidy up > analyze75write, but I'll send it on later this week if I can. > > Adam Hi Adam Thank you for the functions. I have just made the commit and added them to the package. I have added your e-mail to the copyright notice but let me know if you have another address that you prefer. I can wait a bit more to have the whole analyze75 set of functions. If you are already tidying up the next function, would be cool if you could follow some of the standards of Octave core (most in Octave Forge don't follow it but I find they good standards). Here's some: * indent the function body (this will save from writing end %function) * spaces after function names * no spaces after variables for indexing * user @var for variables name in the help text (do not capitalize them) I'd suggest the others but it seems to me that you want to keep your code Matlab compatible. Is that correct? Carnë |
|
From: Carnë D. <car...@gm...> - 2012-09-24 18:46:26
|
On 24 September 2012 18:12, Paul Dreik <sl...@pa...> wrote: > Maybe it is good to rename the trunk _trunk or something (for the old > repository), so people commiting to the wrong repository notice the > difference. Unfortunately one then notices the change at a late stage, > but that is better than committing and not knowing it was for a dead end > repository. > > Paul I'd settle for just removing the damn thing... Carnë |
|
From: Paul D. <sl...@pa...> - 2012-09-24 16:12:39
|
Maybe it is good to rename the trunk _trunk or something (for the old repository), so people commiting to the wrong repository notice the difference. Unfortunately one then notices the change at a late stage, but that is better than committing and not knowing it was for a dead end repository. Paul Carnë Draug skrev 2012-09-24 14.36: > On 23 September 2012 12:08, Carnë Draug <car...@gm...> wrote: >> Hi everyone >> >> with the upgrade in sourceforge the location for the repository >> changed so you should make a new checkout. See message below from >> sourceforge. >> >> Carnë >> >> ---------- Forwarded message ---------- >> From: SourceForge.net <nor...@in...> >> Date: 23 September 2012 06:59 >> Subject: SourceForge Repo Clone Complete >> To: no...@in... >> >> >> Your cloned repository code in project octave is now ready for use. >> >> Old repository url: http://octave.svn.sourceforge.net/svnroot/octave >> >> New repository checkout command: svn checkout --username=carandraug >> svn+ssh://car...@sv.../p/octave/code/trunk octave-code >> >> You and any other developers should do a fresh checkout using the new >> repository location. > > I just noticed that it's still possible to commit to the old > repository. There's two repositories and this is not git or mercurial. > Both me and Andrius Sutas made a commit to the old one after the > "split". > > Please everyone, make a fresh clone and forget the old one. Sorry for > the trouble this may have caused. > > Carnë > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Octave-dev mailing list > Oct...@li... > https://lists.sourceforge.net/lists/listinfo/octave-dev > |
|
From: Jordi G. H. <jo...@oc...> - 2012-09-24 13:40:55
|
On 22 September 2012 02:23, Gustaf Mårtensson <gu...@me...> wrote: > I was trying to get the database package running on my Octave > istallation on a windows 7 (64-bit) system. The database package is bitrotten. If you are able to discuss and diagnose some of the errors you see, perhaps we can start working together to fix it, if you care enough. - Jordi G. H. |
|
From: Carnë D. <car...@gm...> - 2012-09-24 12:36:39
|
On 23 September 2012 12:08, Carnë Draug <car...@gm...> wrote: > Hi everyone > > with the upgrade in sourceforge the location for the repository > changed so you should make a new checkout. See message below from > sourceforge. > > Carnë > > ---------- Forwarded message ---------- > From: SourceForge.net <nor...@in...> > Date: 23 September 2012 06:59 > Subject: SourceForge Repo Clone Complete > To: no...@in... > > > Your cloned repository code in project octave is now ready for use. > > Old repository url: http://octave.svn.sourceforge.net/svnroot/octave > > New repository checkout command: svn checkout --username=carandraug > svn+ssh://car...@sv.../p/octave/code/trunk octave-code > > You and any other developers should do a fresh checkout using the new > repository location. I just noticed that it's still possible to commit to the old repository. There's two repositories and this is not git or mercurial. Both me and Andrius Sutas made a commit to the old one after the "split". Please everyone, make a fresh clone and forget the old one. Sorry for the trouble this may have caused. Carnë |
|
From: c. <car...@gm...> - 2012-09-24 08:53:23
|
On 24 Sep 2012, at 10:44, Juan Pablo Carbajal wrote: > On Mon, Sep 24, 2012 at 10:21 AM, c. <car...@gm...> wrote: >> >> On 24 Sep 2012, at 09:58, Juan Pablo Carbajal wrote: >> >>> Which if itself is not a bad idea! releasePKG is working fine, we can >>> make a script to generate the html of all packages. >> >> No, we do not want that. that's like the old monolithic build process, >> sounded like a good idea in the beginning, proved to be __BAD__™ in the end. >> Been there already, we don't want to go there again. >> >> c. >> > > I mean it as a one-shot thing, not as a standard procedure. > > Also, detecting where are the hardlinks (and getting rid of them when > possible) is also good. However it can create insurmountable delays. as a one-timer it's of course OK, but I do expect lots of problems. c. |
|
From: Juan P. C. <car...@if...> - 2012-09-24 08:44:51
|
On Mon, Sep 24, 2012 at 10:21 AM, c. <car...@gm...> wrote: > > On 24 Sep 2012, at 09:58, Juan Pablo Carbajal wrote: > >> Which if itself is not a bad idea! releasePKG is working fine, we can >> make a script to generate the html of all packages. > > No, we do not want that. that's like the old monolithic build process, > sounded like a good idea in the beginning, proved to be __BAD__™ in the end. > Been there already, we don't want to go there again. > > c. > I mean it as a one-shot thing, not as a standard procedure. Also, detecting where are the hardlinks (and getting rid of them when possible) is also good. However it can create insurmountable delays. -- M. Sc. Juan Pablo Carbajal ----- PhD Student University of Zürich http://ailab.ifi.uzh.ch/carbajal/ |
|
From: Carnë D. <car...@gm...> - 2012-09-24 08:40:47
|
On 21 September 2012 16:10, adam aitkenhead <ada...@ho...> wrote: >> From: car...@gm... >> Date: Fri, 21 Sep 2012 13:53:56 +0200 >> >> On 21 September 2012 10:18, adam aitkenhead <ada...@ho...> >> wrote: >> > The underlying read function has a different calling syntax from Matlab, >> > as >> > it reads both the header and the image in one go (I wrote it like that >> > before I realized there were similar functions in Matlab). However I've >> > also written functions which call it using the same format as >> > analyze75info >> > and analyze75read. This does mean that it runs slower than Matlab, but >> > it >> > shouldn't be difficult to change it to read only the appropriate parts >> > if >> > needed. >> >> It's ok to do more than the matlab functions, there's plenty of >> examples where that is the case. It's just not very good to have >> conflicts with their API. So if your analyze75read works as in >> "[image, header] = analyze75read (fname)", it's still matlab >> compatible while being more useful at the same time. It seems to me >> that matlab also has a analyze75info function, maybe you'd like to >> make it compatible? I'm planning on making a release of the image >> package Sunday in case you are interested in having your functions >> included now. Otherwise they can still be included on the next >> release. >> >> Carnë > > I probably won't have a chance to send it before Sunday (the files are on my > laptop which I don't have with me this weekend). But I should be able to > send it next week, so the following release should be no problem. > Thanks, > Adam This is taking me more time than initially expected. If you want, could still try to add them to this release. Carnë |
|
From: c. <car...@gm...> - 2012-09-24 08:21:14
|
On 24 Sep 2012, at 09:58, Juan Pablo Carbajal wrote: > Which if itself is not a bad idea! releasePKG is working fine, we can > make a script to generate the html of all packages. No, we do not want that. that's like the old monolithic build process, sounded like a good idea in the beginning, proved to be __BAD__™ in the end. Been there already, we don't want to go there again. c. |
|
From: Juan P. C. <car...@if...> - 2012-09-24 07:58:39
|
On Mon, Sep 24, 2012 at 9:48 AM, c. <car...@gm...> wrote: > > On 24 Sep 2012, at 09:23, Juan Pablo Carbajal wrote: > >> On Mon, Sep 24, 2012 at 8:54 AM, Carnë Draug <car...@gm...> wrote: >>> On 23 September 2012 14:47, Juan Pablo Carbajal <car...@if...> wrote: >>>> @Carnë: If you need help updatign the text in the website let me know, >>>> we should use this opportunity to put it up to date. >>> >>> I was more of a midndset to move the instructions to the wiki... >>> Should make it easier to change in the future. >>> >>> Carnë >> >> Sounds great, will also help in the transition to Agora. >> Ok, can you take the lead and create the corresponding pages so we can >> stat updating the content? >> >> When the process is over, I guess you will empty this page >> http://octave.sourceforge.net/developers.html >> >> and just live a nice link to the wiki, right? > > I'd be careful with such changes, the autogenerated files for package documentation have hardcoded links to various pages on the Octave-Forge website, > if you start moving things around those links will be broken and ALL packages will have to be generated again. > c. Which if itself is not a bad idea! releasePKG is working fine, we can make a script to generate the html of all packages. -- M. Sc. Juan Pablo Carbajal ----- PhD Student University of Zürich http://ailab.ifi.uzh.ch/carbajal/ |
|
From: Juan P. C. <car...@if...> - 2012-09-24 07:56:46
|
On Mon, Sep 24, 2012 at 9:50 AM, c. <car...@gm...> wrote: > > On 24 Sep 2012, at 08:55, Paul Dreik wrote: > >> That is why I asked if there is a package that improves from it - I >> guess a package has to use multiple source files, where at least some >> are nondependent so they can be compiled in parallel. > > openmpi_ext is a good example for this, it has many .cc files that can all be compiled independently. > c. > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Octave-dev mailing list > Oct...@li... > https://lists.sourceforge.net/lists/listinfo/octave-dev I created a dedicated page for the effort. http://wiki.octave.org/Code_sprint:_pkg.m Some items need a better description. I did not copy the "more like apt-get" item cause is too unspecific. If you know what was meant in any of the item, maybe you can add some user-stories to its description. FLOSS Scheduling tool? -- M. Sc. Juan Pablo Carbajal ----- PhD Student University of Zürich http://ailab.ifi.uzh.ch/carbajal/ |
|
From: c. <car...@gm...> - 2012-09-24 07:50:05
|
On 24 Sep 2012, at 08:55, Paul Dreik wrote: > That is why I asked if there is a package that improves from it - I > guess a package has to use multiple source files, where at least some > are nondependent so they can be compiled in parallel. openmpi_ext is a good example for this, it has many .cc files that can all be compiled independently. c. |
|
From: c. <car...@gm...> - 2012-09-24 07:48:19
|
On 24 Sep 2012, at 09:23, Juan Pablo Carbajal wrote: > On Mon, Sep 24, 2012 at 8:54 AM, Carnë Draug <car...@gm...> wrote: >> On 23 September 2012 14:47, Juan Pablo Carbajal <car...@if...> wrote: >>> @Carnë: If you need help updatign the text in the website let me know, >>> we should use this opportunity to put it up to date. >> >> I was more of a midndset to move the instructions to the wiki... >> Should make it easier to change in the future. >> >> Carnë > > Sounds great, will also help in the transition to Agora. > Ok, can you take the lead and create the corresponding pages so we can > stat updating the content? > > When the process is over, I guess you will empty this page > http://octave.sourceforge.net/developers.html > > and just live a nice link to the wiki, right? I'd be careful with such changes, the autogenerated files for package documentation have hardcoded links to various pages on the Octave-Forge website, if you start moving things around those links will be broken and ALL packages will have to be generated again. c. |
541 messages has been excluded from this view by a project administrator.
