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: Carnë D. <car...@gm...> - 2012-09-04 02:54:31
|
On 4 September 2012 03:14, Jordi Gutiérrez Hermoso <jo...@oc...> wrote: > I've done a few fixes to bwlabeln in svn so that > > 1) it doesn't segfault (or at least I couldn't devise a test that > made it segfault) > 2) It has a help text > 3) it errors out gracefully > 4) it actually does what it's supposed to > > Sadly, it's slow. :-( But fast enough fo rmy purposes. I would > appreciate if anyone who cares about 3d images could test it. > > I am therefore considering this done, and I will be doing a release of > the image package soon. For my purposes, I need to remove a few > unnecessary trivial checks for two-dimensionality in regionprops. > > Comments? > > - Jordi G. H. I have some 3D images and will be able to test that later this week (I'm moving to Germany at the moment). About making a new release of the image, do you really need it? If so, maybe make just one release with that new function (as if there was a default and stable branch). There's a lot of changes and new functions and I'm not sure if it's in good state to be released just yet. Mmany functions don't have tests and since the API for some has changed to be matlab compatible a new release made now is likely to be quite buggy. I'm trying to go at it one function at a time and make a major release but that will take a while. Carnë |
|
From: Jordi G. H. <jo...@oc...> - 2012-09-04 02:14:06
|
I've done a few fixes to bwlabeln in svn so that
1) it doesn't segfault (or at least I couldn't devise a test that
made it segfault)
2) It has a help text
3) it errors out gracefully
4) it actually does what it's supposed to
Sadly, it's slow. :-( But fast enough fo rmy purposes. I would
appreciate if anyone who cares about 3d images could test it.
I am therefore considering this done, and I will be doing a release of
the image package soon. For my purposes, I need to remove a few
unnecessary trivial checks for two-dimensionality in regionprops.
Comments?
- Jordi G. H.
|
|
From: Michael D G. <mic...@gm...> - 2012-09-03 22:03:45
|
On 09/03/2012 01:50 PM, Carnë Draug wrote: > Or, maybe I could translate the manual on this website > >http://www.gnu.org/software/octave/octave.pdf > > It would not be good to start from the current English PDF. This is created by the Octave build system from a set of input files. An important challenge will be how to keep the translation in step with the English version. The English language files are updated quite often, but the people doing this typically do not know Chinese. Some fairly automatic means to telling the translators that a English file has been updated will be needed. First, you need to learn how the current Manual gets built. You can learn this by studying the build process from the Octave source. This will take some work, but it would be of major value if you could complete a translation, and I am sure that other maintainers would help with technical issues about the Octave system. I have done translations of German and French technical material lately and one thing I know (for these languages) is that Google translate is very helpful. I think that it knows Chinese, too. It cannot handle whole sections (Chapters, say) of text, but it is good at phrases and sentences -- it lets you ask for alternate translations, for instance. So, it helps recall particular words that you were searching for, for example. So, I hope you will not get discouraged by how much you need to learn -- it will not be all that hard. And, it will be of great value to the user community. Good luck! Michael |
|
From: c. <car...@gm...> - 2012-09-03 20:35:51
|
On 3 Sep 2012, at 22:12, Rafael Laboissiere wrote: > * Thomas Weber <tw...@de...> [2012-09-03 20:04]: > >> On Sun, Sep 02, 2012 at 09:39:03PM +0200, c. wrote: >>> I changed the permissions locally and tried to commit the changes but it seems nothing happened. >>> I'm not sure if/how file permissions can be stored in subversion, the executable property can be set >>> with "propset" but I don't know how to change the other permissions. >>> If you do please go ahead and change them. >> >> Okay, it seems that I indeed don't understand something here. I thought >> that Rafael just meant the executable bit. Rafael, what are the >> permissions you are talking about? Apart from the executable bit, the >> permissions in the tarball are 644 after unpacking, which seems >> appropriate. > > I see permissions 755 for some .m files in the tarball: > > $ tar tfvz secs1d-0.0.9.tar.gz | grep inst > drwxr-xr-x carlo/staff 0 2012-03-30 00:56 secs1d-0.0.9/inst/ > -rwxr-xr-x carlo/staff 10663 2012-03-30 00:54 secs1d-0.0.9/inst/secs1d_dd_gummel_map.m > -rw-r--r-- carlo/staff 8319 2012-03-30 00:54 secs1d-0.0.9/inst/secs1d_dd_newton.m > -rwxr-xr-x carlo/staff 5653 2012-03-30 00:54 secs1d-0.0.9/inst/secs1d_nlpoisson_newton.m > -rw-r--r-- carlo/staff 1256 2012-03-26 00:44 secs1d-0.0.9/inst/secs1d_physical_constants.m > -rwxr-xr-x carlo/staff 3750 2012-03-26 00:44 secs1d-0.0.9/inst/secs1d_silicon_material_properties.m > > Rafael I removed the property svn:executable (which was indeed set) from the files inst/secs1d_dd_gummel_map.m inst/secs1d_nlpoisson_newton.m inst/secs1d_silicon_material_properties.m I hope this fixes the problem. Thanks! c. |
|
From: Rafael L. <ra...@la...> - 2012-09-03 20:13:04
|
* Thomas Weber <tw...@de...> [2012-09-03 20:04]: > On Sun, Sep 02, 2012 at 09:39:03PM +0200, c. wrote: > > I changed the permissions locally and tried to commit the changes but it seems nothing happened. > > I'm not sure if/how file permissions can be stored in subversion, the executable property can be set > > with "propset" but I don't know how to change the other permissions. > > If you do please go ahead and change them. > > Okay, it seems that I indeed don't understand something here. I thought > that Rafael just meant the executable bit. Rafael, what are the > permissions you are talking about? Apart from the executable bit, the > permissions in the tarball are 644 after unpacking, which seems > appropriate. I see permissions 755 for some .m files in the tarball: $ tar tfvz secs1d-0.0.9.tar.gz | grep inst drwxr-xr-x carlo/staff 0 2012-03-30 00:56 secs1d-0.0.9/inst/ -rwxr-xr-x carlo/staff 10663 2012-03-30 00:54 secs1d-0.0.9/inst/secs1d_dd_gummel_map.m -rw-r--r-- carlo/staff 8319 2012-03-30 00:54 secs1d-0.0.9/inst/secs1d_dd_newton.m -rwxr-xr-x carlo/staff 5653 2012-03-30 00:54 secs1d-0.0.9/inst/secs1d_nlpoisson_newton.m -rw-r--r-- carlo/staff 1256 2012-03-26 00:44 secs1d-0.0.9/inst/secs1d_physical_constants.m -rwxr-xr-x carlo/staff 3750 2012-03-26 00:44 secs1d-0.0.9/inst/secs1d_silicon_material_properties.m Rafael |
|
From: c. <car...@gm...> - 2012-09-03 20:10:30
|
On 3 Sep 2012, at 20:04, Thomas Weber wrote: > Okay, it seems that I indeed don't understand something here. I thought > that Rafael just meant the executable bit. Rafael, what are the > permissions you are talking about? Apart from the executable bit, the > permissions in the tarball are 644 after unpacking, which seems > appropriate. In my local copy some of the files listed by Raphael had mode 640, is this not the case in the tarball? > Thomas c. |
|
From: Thomas W. <tw...@de...> - 2012-09-03 18:05:13
|
On Sun, Sep 02, 2012 at 09:39:03PM +0200, c. wrote: > I changed the permissions locally and tried to commit the changes but it seems nothing happened. > I'm not sure if/how file permissions can be stored in subversion, the executable property can be set > with "propset" but I don't know how to change the other permissions. > If you do please go ahead and change them. Okay, it seems that I indeed don't understand something here. I thought that Rafael just meant the executable bit. Rafael, what are the permissions you are talking about? Apart from the executable bit, the permissions in the tarball are 644 after unpacking, which seems appropriate. Thomas |
|
From: Carnë D. <car...@gm...> - 2012-09-03 17:51:26
|
Always make reply to all including the mailing list. Also avoid top posting (I have readjusted your e-mail to put it on the bottom). This makes it easier for others to follow the conversation. On 3 September 2012 17:58, 胡小柯 <hot...@gm...> wrote: > 2012/9/3 Carnë Draug <car...@gm...>: >> On 3 September 2012 16:19, 胡小柯 <hot...@gm...> wrote: >>> Hi, >>> guys! >>> >>> I am very glad to encounter with octave, but I found that it is not >>> available in Chinese, I mean Chinese Simplified. So I would like to >>> help with translation, and read the translator guide, but it is >>> confusing. Maybe it is outdated, can everybody update it so that I can >>> follow it step by step to translate? >>> >>> Thanks. >>> >>> Regards, >>> hottea >> >> Hi >> >> No one has been working on this anymore. You are free to do so but >> unfortunately it seems that everyone that was related to it are no >> longer involved. See >> http://octave.1599824.n4.nabble.com/Help-wanted-to-translate-GNU-Octave-documentation-into-Chinese-td4633495.html >> >> I believe there's better methods to have translations, but they would >> need to be implemented on octave core (I'm cc,ing the mailing list for >> octave maintainers). Maybe you would like to start working on it? >> >> Carnë > > so there used to be someone would like to help with translation, but > finally gave up because they didn't know how-to or there isn't a clear > translator guide ? > > My problem is that I could not follow the guide to translate, can you > tell me how to? I need brief and clear steps. I even didn't know what > I need to translate after reading the guide. Tell me where are the > files for translation and what tolls are available, it seems poedit is > not available. Or, maybe I could translate the manual on this website > http://www.gnu.org/software/octave/octave.pdf > > And I got some material available in Chinese Traditional on this > website https://sites.google.com/site/octavetech/ > But it is seems it won't updated anymore and it have a long way to > complete. And yeah, I am translating the manual, but only the Chapter > 15 Plotting, because I am now needing it. There used to be some people who knew how this is works. But no one has doing anything about it for ages. The link I sent you was also from a chinese person interested on translating a few months that got stuck. I believe the way it worked was that a package would shadow the core help function and would show a translated help text if available. So only the help text of functions, not the manual would be translated by this method. I can't help you more with this as I never tried do it and don't know the details. Carnë |
|
From: Carnë D. <car...@gm...> - 2012-09-03 15:29:27
|
On 3 September 2012 16:19, 胡小柯 <hot...@gm...> wrote: > Hi, > guys! > > I am very glad to encounter with octave, but I found that it is not > available in Chinese, I mean Chinese Simplified. So I would like to > help with translation, and read the translator guide, but it is > confusing. Maybe it is outdated, can everybody update it so that I can > follow it step by step to translate? > > Thanks. > > Regards, > hottea Hi No one has been working on this anymore. You are free to do so but unfortunately it seems that everyone that was related to it are no longer involved. See http://octave.1599824.n4.nabble.com/Help-wanted-to-translate-GNU-Octave-documentation-into-Chinese-td4633495.html I believe there's better methods to have translations, but they would need to be implemented on octave core (I'm cc,ing the mailing list for octave maintainers). Maybe you would like to start working on it? Carnë |
|
From: 胡小柯 <hot...@gm...> - 2012-09-03 15:19:32
|
Hi, guys! I am very glad to encounter with octave, but I found that it is not available in Chinese, I mean Chinese Simplified. So I would like to help with translation, and read the translator guide, but it is confusing. Maybe it is outdated, can everybody update it so that I can follow it step by step to translate? Thanks. Regards, hottea |
|
From: Juan P. C. <car...@if...> - 2012-09-03 14:39:11
|
Estimada Ing. Laura Gelsi, Mi nombre es Juan Pablo Carbajal, colaboro en el desarrollo del programa libre para analisis numérico GNU Octave (http://www.gnu.org/software/octave/ altamente compatible con Matlab y con la misma sintaxis). He leido su articulo RECONOCIMIENTO RÁPIDO DE OBJETOS (http://anales.fisica.org.ar/journal/index.php/analesafa/article/view/22), publicado en los anales de la AFA este año. Me gustaría saber si el código se encuentra disponible bajo alguna licencia libre (http://es.wikipedia.org/wiki/Anexo:Licencias_de_software_aprobadas_por_la_FSF). Si ese es el caso me gustaría agregarlo al paquete "image" de GNU Octave (http://octave.sourceforge.net/image/overview.html). De esta manera su código (que conservará su autoría) será obtenible a través de la internet (Muchas distribuciones de linux incluyen los paquetes de GNU Octzave, ejemplo: Debian, Fedora, etc) y a través de la linea de comando de GNU Octave. Espero que comprenda la importancia de compartir el código cientifico de manera que sea accesible para todos (es decir, que no depdenda de software pago para su utilización). Desde ya le agradezco su articulo y su colaboración Atentamente, -- 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-03 13:09:24
|
On Mon, Sep 3, 2012 at 12:49 AM, Andrius Sutas <and...@gm...> wrote: > Hey everyone, > > from now on "serial" and "i2c" packages are merged to a single package > called "instrument-control". > > Function calls remain exactly the same. > > ------------------------------------------------------------------------------ > 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 > Thank you Andrius! I see you have improved the documentation of many functions. Good job! Also I noted you are suing the "autoload" function in the PKG_ADD script. This sounds like a good idea (but not sure if it really is, definitely is cleaner than what we are doing in geometry and many other), but there is no PKG_DEL and consequently when running > pkg unload instrument-control All the functions are still in the search path. I see no "inverse" to autoload, so you can proceed as we are doing in the PKG_* scripts in geometry, mechanics, ocs or any other (multi-)package. Does anybody knows an inverse to "autoload"? Thanks and keep the good work. -- M. Sc. Juan Pablo Carbajal ----- PhD Student University of Zürich http://ailab.ifi.uzh.ch/carbajal/ |
|
From: Philip N. <pr....@hc...> - 2012-09-03 10:30:22
|
PMFJI but, uhm.... Lukas Reichlin wrote: > On 03.09.2012, at 10:39, Rafael Laboissiere<ra...@la...> wrote: > >> * Rafael Laboissiere<ra...@la...> [2012-08-30 23:47]: >> >>> * Carnë Draug<car...@gm...> [2012-08-27 16:43]: >>> >>>> a new release of control package is out, version 2.3.53, by Lukas Reichlin. >>> >>> In exercising the tests in inst/@lti/minreal.m, I got the error below. >>> Is it normal? > Hi Rafael, > > You can check whether the observed and expected results are equivalent state-space models (i.e. state-transformation, see command prescale for formulae). This can be done, e.g., by inspection of the Hankel singular values (command hsvd), time response (step, impulse) or frequency response (sigma). > If they are the same, there should be nothing to worry about. If you want the same results, use Reference BLAS (and LAPACK) from www.netlib.org instead of ATLAS which you are probably using. The SLICOT authors recommend the use of the reference implementations. Correct results are more important than minor speed advantages of automatically tuned linear algebra software, aren't they? :-) ... shouldn't such an interpretation be reflected in the tests then, rather than a plain "assert" comparison that depends on what (allowed!) dependencies happen to be in place. Currently the test just seems to yield confusion. Philip |
|
From: Lukas R. <luk...@gm...> - 2012-09-03 10:03:33
|
On 03.09.2012, at 10:39, Rafael Laboissiere <ra...@la...> wrote: > * Rafael Laboissiere <ra...@la...> [2012-08-30 23:47]: > >> * Carnë Draug <car...@gm...> [2012-08-27 16:43]: >> >>> a new release of control package is out, version 2.3.53, by Lukas Reichlin. >> >> In exercising the tests in inst/@lti/minreal.m, I got the error below. >> Is it normal? >> >> I am running octave 3.6.2 on a Debian unstable system. >> >> [snip] > > Testing ltimodels and bstmodred also yield errors, cf below. > > Rafael > > > ############################################################################# > > [ltimodels] > ***** assert (ac, ac_e, 1e-4); > !!!!! test failed > assert (ac,ac_e,1e-4) expected > 0.00000 0.00000 0.00000 0.00000 -1.26270 0.43340 0.46660 > 0.00000 2.00000 0.00000 -3.74170 -0.85200 0.29240 -0.43420 > 0.00000 0.00000 1.78620 0.37800 -0.26510 -0.77230 0.00000 > 0.00000 0.00000 0.00000 3.74170 0.85200 -0.29240 0.43420 > 0.00000 0.00000 0.00000 0.00000 -1.55400 0.53340 0.57420 > 0.00000 0.00000 0.00000 0.00000 -0.65330 0.22420 0.24140 > 0.00000 0.00000 0.00000 0.00000 -0.58920 0.20220 0.21770 > but got > 0.00000 -0.00000 -0.00000 0.00000 1.35857 -0.38229 -0.09025 > 0.00000 2.00000 0.00000 -3.74166 0.87321 0.48735 0.00000 > 0.00000 0.00000 1.78619 0.37796 -0.03591 0.06435 -0.81316 > 0.00000 0.00000 0.00000 3.74166 -0.87321 -0.48735 -0.00000 > 0.00000 0.00000 0.00000 0.00000 1.84482 -0.51912 -0.12255 > 0.00000 0.00000 0.00000 0.00000 -0.51537 0.14502 0.03424 > 0.00000 0.00000 0.00000 0.00000 -0.14986 0.04217 0.00996 > maximum absolute error 3.39882 exceeds tolerance 0.0001 > shared variables > scalar structure containing the fields: > > ac = > > 0.00000 -0.00000 -0.00000 0.00000 1.35857 -0.38229 -0.09025 > 0.00000 2.00000 0.00000 -3.74166 0.87321 0.48735 0.00000 > 0.00000 0.00000 1.78619 0.37796 -0.03591 0.06435 -0.81316 > 0.00000 0.00000 0.00000 3.74166 -0.87321 -0.48735 -0.00000 > 0.00000 0.00000 0.00000 0.00000 1.84482 -0.51912 -0.12255 > 0.00000 0.00000 0.00000 0.00000 -0.51537 0.14502 0.03424 > 0.00000 0.00000 0.00000 0.00000 -0.14986 0.04217 0.00996 > > ec = > > 1.83254 1.00000 2.37525 0.00000 0.97073 -1.73928 -0.18050 > -0.48868 0.00000 0.37702 -0.53452 0.02539 -0.04550 0.57499 > 0.17277 -0.00000 -0.13330 -1.13389 0.01796 -0.03217 0.40658 > 0.00000 0.00000 0.00000 -0.00000 -0.87321 -0.48735 0.00000 > 0.00000 0.00000 0.00000 0.00000 1.00048 -0.00173 0.02189 > 0.00000 0.00000 0.00000 0.00000 0.00000 1.00155 -0.03914 > 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 1.22226 > > bc = > > 1.00000 2.00000 3.00000 > 2.00000 1.00000 0.00000 > 0.00000 0.00000 0.00000 > 0.00000 0.00000 0.00000 > 0.00000 0.00000 0.00000 > 0.00000 0.00000 0.00000 > 0.00000 0.00000 0.00000 > > cc = > > Columns 1 through 5: > > 1.5181e-16 1.0000e+00 -9.6723e-17 1.8014e-16 1.3586e+00 > -3.6651e-01 9.6902e-18 -9.8026e-01 -1.6036e+00 2.5394e-02 > > Columns 6 and 7: > > -3.8229e-01 -9.0251e-02 > -4.5500e-02 5.7499e-01 > > q = > > 0.00000 1.00000 -0.00000 0.00000 0.00000 0.00000 0.00000 > 0.00000 -0.00000 0.70711 0.00000 -0.03807 0.06808 -0.70279 > 0.00000 -0.00000 -0.00000 -0.00000 0.87278 0.48811 0.00000 > 0.00000 0.00000 0.00000 -1.00000 -0.00000 -0.00000 -0.00000 > 0.00000 0.00000 -0.00000 0.00000 0.48513 -0.86746 -0.11031 > 0.00000 -0.00000 0.70711 0.00000 0.03807 -0.06808 0.70279 > 1.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 > > z = > > 0.00000 1.00000 0.00000 0.00000 0.00000 0.00000 0.00000 > 0.61085 -0.00000 0.79175 0.00000 0.00000 0.00000 0.00000 > -0.48868 0.00000 0.37702 -0.53452 0.02539 -0.04550 0.57499 > -0.00000 0.00000 0.00000 -0.00000 0.48536 -0.86964 -0.09025 > -0.61085 0.00000 0.47128 0.26726 -0.02539 0.04550 -0.57499 > 0.12217 -0.00000 -0.09426 -0.80178 -0.02539 0.04550 -0.57499 > 0.00000 -0.00000 -0.00000 0.00000 0.87321 0.48735 0.00000 > > ncont = 3 > ac_e = > > 0.00000 0.00000 0.00000 0.00000 -1.26270 0.43340 0.46660 > 0.00000 2.00000 0.00000 -3.74170 -0.85200 0.29240 -0.43420 > 0.00000 0.00000 1.78620 0.37800 -0.26510 -0.77230 0.00000 > 0.00000 0.00000 0.00000 3.74170 0.85200 -0.29240 0.43420 > 0.00000 0.00000 0.00000 0.00000 -1.55400 0.53340 0.57420 > 0.00000 0.00000 0.00000 0.00000 -0.65330 0.22420 0.24140 > 0.00000 0.00000 0.00000 0.00000 -0.58920 0.20220 0.21770 > > ec_e = > > -1.83250 1.00000 2.37520 0.00000 -0.82140 0.28190 1.80160 > 0.48870 0.00000 0.37700 -0.53450 0.18740 0.54610 0.00000 > -0.17280 0.00000 -0.13330 -1.13390 0.13250 0.38610 0.00000 > 0.00000 0.00000 0.00000 0.00000 0.85200 -0.29240 0.43420 > 0.00000 0.00000 0.00000 0.00000 -1.02600 -0.14960 0.00000 > 0.00000 0.00000 0.00000 0.00000 0.00000 1.19370 0.00000 > 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 1.00000 > > bc_e = > > 1 2 3 > 2 1 0 > 0 0 0 > 0 0 0 > 0 0 0 > 0 0 0 > 0 0 0 > > cc_e = > > 0.00000 1.00000 0.00000 0.00000 -1.26270 0.43340 0.46660 > 0.36650 0.00000 -0.98030 -1.60360 0.18740 0.54610 0.00000 > > q_e = > > 0.00000 1.00000 0.00000 0.00000 0.00000 0.00000 0.00000 > 0.00000 0.00000 0.70710 0.00000 0.27400 -0.65190 0.00000 > 0.00000 0.00000 0.00000 0.00000 0.83040 0.34910 -0.43420 > 0.00000 0.00000 0.00000 -1.00000 0.00000 0.00000 0.00000 > 0.00000 0.00000 0.00000 0.00000 0.40030 0.16830 0.90080 > 0.00000 0.00000 0.70710 0.00000 -0.27400 0.65190 0.00000 > 1.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 > > z_e = > > 0.00000 1.00000 0.00000 0.00000 0.00000 0.00000 0.00000 > -0.61080 0.00000 0.79170 0.00000 0.00000 0.00000 0.00000 > 0.48870 0.00000 0.37700 -0.53450 0.18740 0.54610 0.00000 > 0.00000 0.00000 0.00000 0.00000 -0.41070 0.14100 0.90080 > 0.61080 0.00000 0.47130 0.26730 -0.18740 -0.54610 0.00000 > -0.12220 0.00000 -0.09430 -0.80180 -0.18740 -0.54610 0.00000 > 0.00000 0.00000 0.00000 0.00000 -0.85200 0.29240 -0.43420 > > ncont_e = 3 > > [bstmodred] > ***** assert (Mo, Me, 1e-4); > !!!!! test failed > assert (Mo,Me,1e-4) expected > 1.27290 0.00000 6.59470 0.00000 -3.42290 0.13310 -0.13310 > 0.00000 0.81690 0.00000 2.48210 0.00000 -0.08620 -0.08620 > -2.98890 0.00000 -2.90280 0.00000 -0.36920 -2.67770 2.67770 > 0.00000 -3.39210 0.00000 -3.11260 0.00000 -3.57670 -3.57670 > -1.47670 0.00000 -2.03390 0.00000 -0.61070 -2.30330 2.30330 > -0.69070 -0.68820 0.07790 0.09580 -0.00380 0.00000 0.00000 > 0.06760 0.00000 0.65320 0.00000 -0.75220 0.00000 0.00000 > 0.69070 -0.68820 -0.07790 0.09580 0.00380 0.00000 0.00000 > but got > 1.27295 0.00000 -6.59466 0.00000 -3.42287 -0.13307 0.13307 > -0.00000 0.81688 0.00000 2.48210 0.00000 0.08620 0.08620 > 2.98890 -0.00000 -2.90283 0.00000 0.36919 -2.67775 2.67775 > -0.00000 -3.39208 -0.00000 -3.11263 0.00000 3.57669 3.57669 > -1.47666 0.00000 2.03393 0.00000 -0.61070 2.30328 -2.30328 > 0.69073 0.68823 0.07791 -0.09576 0.00376 0.00000 0.00000 > -0.06755 -0.00000 0.65316 0.00000 0.75223 0.00000 0.00000 > -0.69073 0.68823 -0.07791 -0.09576 -0.00376 0.00000 0.00000 > maximum absolute error 13.1894 exceeds tolerance 0.0001 > shared variables > scalar structure containing the fields: > > Mo = > > 1.27295 0.00000 -6.59466 0.00000 -3.42287 -0.13307 0.13307 > -0.00000 0.81688 0.00000 2.48210 0.00000 0.08620 0.08620 > 2.98890 -0.00000 -2.90283 0.00000 0.36919 -2.67775 2.67775 > -0.00000 -3.39208 -0.00000 -3.11263 0.00000 3.57669 3.57669 > -1.47666 0.00000 2.03393 0.00000 -0.61070 2.30328 -2.30328 > 0.69073 0.68823 0.07791 -0.09576 0.00376 0.00000 0.00000 > -0.06755 -0.00000 0.65316 0.00000 0.75223 0.00000 0.00000 > -0.69073 0.68823 -0.07791 -0.09576 -0.00376 0.00000 0.00000 > > Me = > > 1.27290 0.00000 6.59470 0.00000 -3.42290 0.13310 -0.13310 > 0.00000 0.81690 0.00000 2.48210 0.00000 -0.08620 -0.08620 > -2.98890 0.00000 -2.90280 0.00000 -0.36920 -2.67770 2.67770 > 0.00000 -3.39210 0.00000 -3.11260 0.00000 -3.57670 -3.57670 > -1.47670 0.00000 -2.03390 0.00000 -0.61070 -2.30330 2.30330 > -0.69070 -0.68820 0.07790 0.09580 -0.00380 0.00000 0.00000 > 0.06760 0.00000 0.65320 0.00000 -0.75220 0.00000 0.00000 > 0.69070 -0.68820 -0.07790 0.09580 0.00380 0.00000 0.00000 > > Info = > > scalar structure containing the fields: > > n = 7 > ns = 7 > hsv = > > 0.880263 > 0.850619 > 0.803778 > 0.449390 > 0.397312 > 0.021408 > 0.020850 > > nu = 0 > nr = 5 > > HSVe = > > 0.880300 > 0.850600 > 0.803800 > 0.449400 > 0.397300 > 0.021400 > 0.020900 Hi Rafael, You can check whether the observed and expected results are equivalent state-space models (i.e. state-transformation, see command prescale for formulae). This can be done, e.g., by inspection of the Hankel singular values (command hsvd), time response (step, impulse) or frequency response (sigma). If they are the same, there should be nothing to worry about. If you want the same results, use Reference BLAS (and LAPACK) from www.netlib.org instead of ATLAS which you are probably using. The SLICOT authors recommend the use of the reference implementations. Correct results are more important than minor speed advantages of automatically tuned linear algebra software, aren't they? :-) Regards, Lukas |
|
From: Rafael L. <ra...@la...> - 2012-09-03 08:39:08
|
* Rafael Laboissiere <ra...@la...> [2012-08-30 23:47]:
> * Carnë Draug <car...@gm...> [2012-08-27 16:43]:
>
> > a new release of control package is out, version 2.3.53, by Lukas Reichlin.
>
> In exercising the tests in inst/@lti/minreal.m, I got the error below.
> Is it normal?
>
> I am running octave 3.6.2 on a Debian unstable system.
>
> [snip]
Testing ltimodels and bstmodred also yield errors, cf below.
Rafael
#############################################################################
[ltimodels]
***** assert (ac, ac_e, 1e-4);
!!!!! test failed
assert (ac,ac_e,1e-4) expected
0.00000 0.00000 0.00000 0.00000 -1.26270 0.43340 0.46660
0.00000 2.00000 0.00000 -3.74170 -0.85200 0.29240 -0.43420
0.00000 0.00000 1.78620 0.37800 -0.26510 -0.77230 0.00000
0.00000 0.00000 0.00000 3.74170 0.85200 -0.29240 0.43420
0.00000 0.00000 0.00000 0.00000 -1.55400 0.53340 0.57420
0.00000 0.00000 0.00000 0.00000 -0.65330 0.22420 0.24140
0.00000 0.00000 0.00000 0.00000 -0.58920 0.20220 0.21770
but got
0.00000 -0.00000 -0.00000 0.00000 1.35857 -0.38229 -0.09025
0.00000 2.00000 0.00000 -3.74166 0.87321 0.48735 0.00000
0.00000 0.00000 1.78619 0.37796 -0.03591 0.06435 -0.81316
0.00000 0.00000 0.00000 3.74166 -0.87321 -0.48735 -0.00000
0.00000 0.00000 0.00000 0.00000 1.84482 -0.51912 -0.12255
0.00000 0.00000 0.00000 0.00000 -0.51537 0.14502 0.03424
0.00000 0.00000 0.00000 0.00000 -0.14986 0.04217 0.00996
maximum absolute error 3.39882 exceeds tolerance 0.0001
shared variables
scalar structure containing the fields:
ac =
0.00000 -0.00000 -0.00000 0.00000 1.35857 -0.38229 -0.09025
0.00000 2.00000 0.00000 -3.74166 0.87321 0.48735 0.00000
0.00000 0.00000 1.78619 0.37796 -0.03591 0.06435 -0.81316
0.00000 0.00000 0.00000 3.74166 -0.87321 -0.48735 -0.00000
0.00000 0.00000 0.00000 0.00000 1.84482 -0.51912 -0.12255
0.00000 0.00000 0.00000 0.00000 -0.51537 0.14502 0.03424
0.00000 0.00000 0.00000 0.00000 -0.14986 0.04217 0.00996
ec =
1.83254 1.00000 2.37525 0.00000 0.97073 -1.73928 -0.18050
-0.48868 0.00000 0.37702 -0.53452 0.02539 -0.04550 0.57499
0.17277 -0.00000 -0.13330 -1.13389 0.01796 -0.03217 0.40658
0.00000 0.00000 0.00000 -0.00000 -0.87321 -0.48735 0.00000
0.00000 0.00000 0.00000 0.00000 1.00048 -0.00173 0.02189
0.00000 0.00000 0.00000 0.00000 0.00000 1.00155 -0.03914
0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 1.22226
bc =
1.00000 2.00000 3.00000
2.00000 1.00000 0.00000
0.00000 0.00000 0.00000
0.00000 0.00000 0.00000
0.00000 0.00000 0.00000
0.00000 0.00000 0.00000
0.00000 0.00000 0.00000
cc =
Columns 1 through 5:
1.5181e-16 1.0000e+00 -9.6723e-17 1.8014e-16 1.3586e+00
-3.6651e-01 9.6902e-18 -9.8026e-01 -1.6036e+00 2.5394e-02
Columns 6 and 7:
-3.8229e-01 -9.0251e-02
-4.5500e-02 5.7499e-01
q =
0.00000 1.00000 -0.00000 0.00000 0.00000 0.00000 0.00000
0.00000 -0.00000 0.70711 0.00000 -0.03807 0.06808 -0.70279
0.00000 -0.00000 -0.00000 -0.00000 0.87278 0.48811 0.00000
0.00000 0.00000 0.00000 -1.00000 -0.00000 -0.00000 -0.00000
0.00000 0.00000 -0.00000 0.00000 0.48513 -0.86746 -0.11031
0.00000 -0.00000 0.70711 0.00000 0.03807 -0.06808 0.70279
1.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000
z =
0.00000 1.00000 0.00000 0.00000 0.00000 0.00000 0.00000
0.61085 -0.00000 0.79175 0.00000 0.00000 0.00000 0.00000
-0.48868 0.00000 0.37702 -0.53452 0.02539 -0.04550 0.57499
-0.00000 0.00000 0.00000 -0.00000 0.48536 -0.86964 -0.09025
-0.61085 0.00000 0.47128 0.26726 -0.02539 0.04550 -0.57499
0.12217 -0.00000 -0.09426 -0.80178 -0.02539 0.04550 -0.57499
0.00000 -0.00000 -0.00000 0.00000 0.87321 0.48735 0.00000
ncont = 3
ac_e =
0.00000 0.00000 0.00000 0.00000 -1.26270 0.43340 0.46660
0.00000 2.00000 0.00000 -3.74170 -0.85200 0.29240 -0.43420
0.00000 0.00000 1.78620 0.37800 -0.26510 -0.77230 0.00000
0.00000 0.00000 0.00000 3.74170 0.85200 -0.29240 0.43420
0.00000 0.00000 0.00000 0.00000 -1.55400 0.53340 0.57420
0.00000 0.00000 0.00000 0.00000 -0.65330 0.22420 0.24140
0.00000 0.00000 0.00000 0.00000 -0.58920 0.20220 0.21770
ec_e =
-1.83250 1.00000 2.37520 0.00000 -0.82140 0.28190 1.80160
0.48870 0.00000 0.37700 -0.53450 0.18740 0.54610 0.00000
-0.17280 0.00000 -0.13330 -1.13390 0.13250 0.38610 0.00000
0.00000 0.00000 0.00000 0.00000 0.85200 -0.29240 0.43420
0.00000 0.00000 0.00000 0.00000 -1.02600 -0.14960 0.00000
0.00000 0.00000 0.00000 0.00000 0.00000 1.19370 0.00000
0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 1.00000
bc_e =
1 2 3
2 1 0
0 0 0
0 0 0
0 0 0
0 0 0
0 0 0
cc_e =
0.00000 1.00000 0.00000 0.00000 -1.26270 0.43340 0.46660
0.36650 0.00000 -0.98030 -1.60360 0.18740 0.54610 0.00000
q_e =
0.00000 1.00000 0.00000 0.00000 0.00000 0.00000 0.00000
0.00000 0.00000 0.70710 0.00000 0.27400 -0.65190 0.00000
0.00000 0.00000 0.00000 0.00000 0.83040 0.34910 -0.43420
0.00000 0.00000 0.00000 -1.00000 0.00000 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000 0.40030 0.16830 0.90080
0.00000 0.00000 0.70710 0.00000 -0.27400 0.65190 0.00000
1.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000
z_e =
0.00000 1.00000 0.00000 0.00000 0.00000 0.00000 0.00000
-0.61080 0.00000 0.79170 0.00000 0.00000 0.00000 0.00000
0.48870 0.00000 0.37700 -0.53450 0.18740 0.54610 0.00000
0.00000 0.00000 0.00000 0.00000 -0.41070 0.14100 0.90080
0.61080 0.00000 0.47130 0.26730 -0.18740 -0.54610 0.00000
-0.12220 0.00000 -0.09430 -0.80180 -0.18740 -0.54610 0.00000
0.00000 0.00000 0.00000 0.00000 -0.85200 0.29240 -0.43420
ncont_e = 3
[bstmodred]
***** assert (Mo, Me, 1e-4);
!!!!! test failed
assert (Mo,Me,1e-4) expected
1.27290 0.00000 6.59470 0.00000 -3.42290 0.13310 -0.13310
0.00000 0.81690 0.00000 2.48210 0.00000 -0.08620 -0.08620
-2.98890 0.00000 -2.90280 0.00000 -0.36920 -2.67770 2.67770
0.00000 -3.39210 0.00000 -3.11260 0.00000 -3.57670 -3.57670
-1.47670 0.00000 -2.03390 0.00000 -0.61070 -2.30330 2.30330
-0.69070 -0.68820 0.07790 0.09580 -0.00380 0.00000 0.00000
0.06760 0.00000 0.65320 0.00000 -0.75220 0.00000 0.00000
0.69070 -0.68820 -0.07790 0.09580 0.00380 0.00000 0.00000
but got
1.27295 0.00000 -6.59466 0.00000 -3.42287 -0.13307 0.13307
-0.00000 0.81688 0.00000 2.48210 0.00000 0.08620 0.08620
2.98890 -0.00000 -2.90283 0.00000 0.36919 -2.67775 2.67775
-0.00000 -3.39208 -0.00000 -3.11263 0.00000 3.57669 3.57669
-1.47666 0.00000 2.03393 0.00000 -0.61070 2.30328 -2.30328
0.69073 0.68823 0.07791 -0.09576 0.00376 0.00000 0.00000
-0.06755 -0.00000 0.65316 0.00000 0.75223 0.00000 0.00000
-0.69073 0.68823 -0.07791 -0.09576 -0.00376 0.00000 0.00000
maximum absolute error 13.1894 exceeds tolerance 0.0001
shared variables
scalar structure containing the fields:
Mo =
1.27295 0.00000 -6.59466 0.00000 -3.42287 -0.13307 0.13307
-0.00000 0.81688 0.00000 2.48210 0.00000 0.08620 0.08620
2.98890 -0.00000 -2.90283 0.00000 0.36919 -2.67775 2.67775
-0.00000 -3.39208 -0.00000 -3.11263 0.00000 3.57669 3.57669
-1.47666 0.00000 2.03393 0.00000 -0.61070 2.30328 -2.30328
0.69073 0.68823 0.07791 -0.09576 0.00376 0.00000 0.00000
-0.06755 -0.00000 0.65316 0.00000 0.75223 0.00000 0.00000
-0.69073 0.68823 -0.07791 -0.09576 -0.00376 0.00000 0.00000
Me =
1.27290 0.00000 6.59470 0.00000 -3.42290 0.13310 -0.13310
0.00000 0.81690 0.00000 2.48210 0.00000 -0.08620 -0.08620
-2.98890 0.00000 -2.90280 0.00000 -0.36920 -2.67770 2.67770
0.00000 -3.39210 0.00000 -3.11260 0.00000 -3.57670 -3.57670
-1.47670 0.00000 -2.03390 0.00000 -0.61070 -2.30330 2.30330
-0.69070 -0.68820 0.07790 0.09580 -0.00380 0.00000 0.00000
0.06760 0.00000 0.65320 0.00000 -0.75220 0.00000 0.00000
0.69070 -0.68820 -0.07790 0.09580 0.00380 0.00000 0.00000
Info =
scalar structure containing the fields:
n = 7
ns = 7
hsv =
0.880263
0.850619
0.803778
0.449390
0.397312
0.021408
0.020850
nu = 0
nr = 5
HSVe =
0.880300
0.850600
0.803800
0.449400
0.397300
0.021400
0.020900
|
|
From: Andrius S. <and...@gm...> - 2012-09-02 22:49:14
|
Hey everyone, from now on "serial" and "i2c" packages are merged to a single package called "instrument-control". Function calls remain exactly the same. |
|
From: c. <car...@gm...> - 2012-09-02 19:39:01
|
On 2 Sep 2012, at 20:38, Thomas Weber wrote: > On Sun, Sep 02, 2012 at 08:08:16PM +0200, c. wrote: >> >> On 2 Sep 2012, at 17:03, Rafael Laboissiere wrote: >> >>> The following files have wrong permissions in the 0.0.9 tarball of >>> secs1d: >>> >>> inst/secs1d_dd_gummel_map.m >>> inst/secs1d_nlpoisson_newton.m >>> inst/secs1d_silicon_material_properties.m >>> >>> Please, fix this in the next release. >>> >>> Thanks, >>> >>> Rafael >> >> thanks, I fixed the permissions in my local copy. >> As that is where I make the release from I think the next release will have correct permissions. > > I think the permissions should be fixed in the SVN repository, too. I > can do this, but I'm hesitating just in case I'm missing something here. I changed the permissions locally and tried to commit the changes but it seems nothing happened. I'm not sure if/how file permissions can be stored in subversion, the executable property can be set with "propset" but I don't know how to change the other permissions. If you do please go ahead and change them. Thanks, c. > Thomas |
|
From: Thomas W. <tw...@de...> - 2012-09-02 18:39:11
|
On Sun, Sep 02, 2012 at 08:08:16PM +0200, c. wrote: > > On 2 Sep 2012, at 17:03, Rafael Laboissiere wrote: > > > The following files have wrong permissions in the 0.0.9 tarball of > > secs1d: > > > > inst/secs1d_dd_gummel_map.m > > inst/secs1d_nlpoisson_newton.m > > inst/secs1d_silicon_material_properties.m > > > > Please, fix this in the next release. > > > > Thanks, > > > > Rafael > > thanks, I fixed the permissions in my local copy. > As that is where I make the release from I think the next release will have correct permissions. I think the permissions should be fixed in the SVN repository, too. I can do this, but I'm hesitating just in case I'm missing something here. Thomas |
|
From: c. <car...@gm...> - 2012-09-02 18:08:17
|
On 2 Sep 2012, at 17:03, Rafael Laboissiere wrote: > The following files have wrong permissions in the 0.0.9 tarball of > secs1d: > > inst/secs1d_dd_gummel_map.m > inst/secs1d_nlpoisson_newton.m > inst/secs1d_silicon_material_properties.m > > Please, fix this in the next release. > > Thanks, > > Rafael thanks, I fixed the permissions in my local copy. As that is where I make the release from I think the next release will have correct permissions. c. |
|
From: Rafael L. <ra...@la...> - 2012-09-02 15:03:54
|
The following files have wrong permissions in the 0.0.9 tarball of
secs1d:
inst/secs1d_dd_gummel_map.m
inst/secs1d_nlpoisson_newton.m
inst/secs1d_silicon_material_properties.m
Please, fix this in the next release.
Thanks,
Rafael
|
|
From: Mike M. <mtm...@ie...> - 2012-09-02 13:58:36
|
On Sun, Sep 2, 2012 at 8:22 AM, Fredrik Lingvall wrote: > Hi all, > > I have Octave configured with --enable-64 and I can't get the image > package to build with this setup: > > octave:6> pkg install -forge image > [...] > > Is there a way to make this work or can I "disable" that the signal > package (which is what I really want to install) depends on the image > package? Yes, simply add -nodeps to your pkg install command. BTW the next release of signal will no longer depend on image. -- mike |
|
From: Fredrik L. <fre...@gm...> - 2012-09-02 12:22:45
|
Hi all, I have Octave configured with --enable-64 and I can't get the image package to build with this setup: octave:6> pkg install -forge image __spatial_filtering__.cc: In function 'ET_OUT entropy_filt(MT&, octave_idx_type, int) [with ET = octave_int<signed char>, MT = intNDArray<octave_int<signed char> >, ET_OUT = double, octave_idx_type = long int]': __spatial_filtering__.cc:558:9: instantiated from here __spatial_filtering__.cc:190:5: error: conversion from 'octave_int<signed char>' to 'long int' is ambiguous /usr/include/octave-3.6.2/octave/../octave/oct-inttypes.h:783:3: note: candidates are: octave_int<T>::operator float() const [with T = signed char] /usr/include/octave-3.6.2/octave/../octave/oct-inttypes.h:781:3: note: octave_int<T>::operator double() const [with T = signed char] /usr/include/octave-3.6.2/octave/../octave/oct-inttypes.h:777:3: note: octave_int<T>::operator T() const [with T = signed char] __spatial_filtering__.cc:192:5: error: conversion from 'octave_int<signed char>' to 'long int' is ambiguous /usr/include/octave-3.6.2/octave/../octave/oct-inttypes.h:783:3: note: candidates are: octave_int<T>::operator float() const [with T = signed char] /usr/include/octave-3.6.2/octave/../octave/oct-inttypes.h:781:3: note: octave_int<T>::operator double() const [with T = signed char] /usr/include/octave-3.6.2/octave/../octave/oct-inttypes.h:777:3: note: octave_int<T>::operator T() const [with T = signed char] __spatial_filtering__.cc: In function 'ET_OUT entropy_filt(MT&, octave_idx_type, int) [with ET = octave_int<unsigned char>, MT = intNDArray<octave_int<unsigned char> >, ET_OUT = double, octave_idx_type = long int]': __spatial_filtering__.cc:560:9: instantiated from here __spatial_filtering__.cc:190:5: error: conversion from 'octave_int<unsigned char>' to 'long int' is ambiguous /usr/include/octave-3.6.2/octave/../octave/oct-inttypes.h:783:3: note: candidates are: octave_int<T>::operator float() const [with T = unsigned char] /usr/include/octave-3.6.2/octave/../octave/oct-inttypes.h:781:3: note: octave_int<T>::operator double() const [with T = unsigned char] /usr/include/octave-3.6.2/octave/../octave/oct-inttypes.h:777:3: note: octave_int<T>::operator T() const [with T = unsigned char] __spatial_filtering__.cc:192:5: error: conversion from 'octave_int<unsigned char>' to 'long int' is ambiguous /usr/include/octave-3.6.2/octave/../octave/oct-inttypes.h:783:3: note: candidates are: octave_int<T>::operator float() const [with T = unsigned char] /usr/include/octave-3.6.2/octave/../octave/oct-inttypes.h:781:3: note: octave_int<T>::operator double() const [with T = unsigned char] /usr/include/octave-3.6.2/octave/../octave/oct-inttypes.h:777:3: note: octave_int<T>::operator T() const [with T = unsigned char] make: *** [__spatial_filtering__.oct] Error 1 'make' returned the following error: make: Entering directory `/tmp/oct-y3b3iW/image-1.0.15/src' mkoctfile -Wall __spatial_filtering__.cc make: Leaving directory `/tmp/oct-y3b3iW/image-1.0.15/src' error: called from `pkg>configure_make' in file /usr/share/octave/3.6.2/m/pkg/pkg.m near line 1384, column 9 error: called from: error: /usr/share/octave/3.6.2/m/pkg/pkg.m at line 826, column 5 error: /usr/share/octave/3.6.2/m/pkg/pkg.m at line 383, column 9 Is there a way to make this work or can I "disable" that the signal package (which is what I really want to install) depends on the image package? Regards, /Fredrik |
|
From: Sébastien V. <seb...@en...> - 2012-08-31 08:39:54
|
"c." <car...@gm...> writes: > On 31 Aug 2012, at 10:00, Sébastien Villemot wrote: >> Note that the next release of Ubuntu will also include openmpi_ext >> 1.0.2, since I recently added it into Debian. > > Is there still time to update openmpi_ext in debian so that the next ubuntu > release will include the current version rather than the 3-years old 1.0.2? > Is there something that can be done upstream to make this more likely to happen? Both Debian and Ubuntu being currently frozen, it is very unlikely that an update is accepted in either of them. Only a critical bug in 1.0.2 could possibly warrant a freeze exception (at least for Debian; I am not much familiar with the rules for Ubuntu). -- .''`. Sébastien Villemot : :' : Debian Maintainer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 |
|
From: Philip N. <pr....@hc...> - 2012-08-31 08:31:49
|
Terry Duell wrote: > On Thu, 30 Aug 2012 19:51:00 +1000, Philip Nienhuis > <pr....@hc...> wrote: > >> Martin Helm wrote: >>> Am 30.08.2012 08:28, schrieb Terry Duell: > [snip] >>> You are not alone with Fedora, the exactly same problem happens on all >>> openSUSE versions as well, I always have to create the appropriate >>> symlinks manually. I am not sure what the correct solution is (changing >>> the package policy for openjdk, creating the symbolic link when the >>> octave forge java package is installed, changing the source code of the >>> of java package). >> >> This always seems to be the case in 64 bit systems (AFAIK also on >> Windows 64b). >> If it gives some comfort: on Mac OSX it is worse. The Java libs and >> executables have been scattered all over the place there and often >> seem to be moved into other locations with new OSX version. > > Thanks for your responses, clearly this isn't just a problem that I have. > Going on a response I got back in Jan, it looks like it is a problem > confined to the 64 bit openjdk packages. Is that an upstream problem > i.e. something the openjdk maintainers can/should fix? Are you sure that on Sun Java this doesn't happen? Anyway it is not a bad idea to ask the openjdk maintainers why this decision was made. In the Octave-forge ML (http://sourceforge.net/mailarchive/forum.php?forum_name=octave-dev, it has a bit of a clumsy interface) there are a few more threads on this. Philip |
|
From: c. <car...@gm...> - 2012-08-31 08:21:47
|
On 31 Aug 2012, at 10:00, Sébastien Villemot wrote: > Sukanta Basu <suk...@gm...> writes: > >>>> The next release of Ubuntu will happen in October and will include >>>> 3.6.2. I will probably wait for this release. > > Note that the next release of Ubuntu will also include openmpi_ext > 1.0.2, since I recently added it into Debian. Is there still time to update openmpi_ext in debian so that the next ubuntu release will include the current version rather than the 3-years old 1.0.2? Is there something that can be done upstream to make this more likely to happen? c. |
541 messages has been excluded from this view by a project administrator.
