ons, 16 06 2010 kl. 19:15 -0400, skrev Alex Lancaster:
> I'm the maintainer for the Fedora package of octave-forge
Thanks for doing that :-)
> I have definitely tracked this down to "ann" being the issue,
> removing the package, makes the crashes go away. Is this a
> known issue with "ann"? Appa
Hi there,
I'm the maintainer for the Fedora package of octave-forge and we
recently have been getting bug reports of crashes with
octave/octave-forge that seem to be traceable back to
problems with the "ann" package, for full details (including
backtrace), see the downstream bug here:
https://b
Thanks for the guick response!
I merged both, headers and sources, into only one header and one source, and
it worked fine independently of the order of loading. That is both
classes/objects are now in the same file.
Thanks again.
Regards,
Pablo
On Miércoles 16 Junio 2010 10:13:21 Michael Gof
Pablo Daniel Pareja Obregón wrote:
> In order to do so, I must implement my own user defined types, as I
> read in [2]. However, after googling a while, I haven't found much
> documentation and examples on how programming my own types (besides
> [2]).
The Coda document was written against 2.1.x a
As the 2 classes/objects are inter-dependent, I think it's better to include
both into the same .oct file. What's happening is that channel.oct is not
loaded into memory when octave loads analoginput.oct, leading to unresolved
references. This does not happen when channel.oct is loaded explicitely
Hi,
I want to implement a "data acquisition package" equivalent to the one
present in Matlab. The main purpose is to access hardware with
measurement purposes (from Measurement Computing and Texas Instruments
for example). The idea is to release it as gpl and when finished
include it as an octave
