Re: OT: phobos name
On Tuesday, 31 July 2012 at 13:16:57 UTC, akaz wrote: I just discovered that. I find it surprisingly. Fear surprisingly - surprising. sorry.
OT: phobos name
According to Wikipedia: Phobos (Ancient Greek: Φόβος, pronounced [pʰóbos], meaning fear or terror) is the personification of fear in Greek mythology. http://en.wikipedia.org/wiki/Phobos_(mythology) I just discovered that. I find it surprisingly. Fear Terror
Re: OT: phobos name
On Tuesday, 31 July 2012 at 13:22:57 UTC, Tobias Brandt wrote: On 31 July 2012 15:16, akaz a...@utopia.com wrote: Phobos and Deimos are the two moons of Mars, which was the original name of D. That, on the other hand, was known to me. What I did not know, was the fear factor... Maybe the library should have been renamed to Deimos? :) By the way, I live in the same city as this guy here. So you may say that I live with Phobos over my head: http://davinci-marsdesign.blogspot.fr/2012/05/scale-of-phobos.html Pretty... scary, isn't?
Re: OT: phobos name
On Tuesday, 31 July 2012 at 13:28:35 UTC, akaz wrote: On Tuesday, 31 July 2012 at 13:22:57 UTC, Tobias Brandt wrote: On 31 July 2012 15:16, akaz a...@utopia.com wrote: Phobos and Deimos are the two moons of Mars, which was the original name of D. That, on the other hand, was known to me. What I did not know, was the fear factor... Maybe the library should have been renamed to Deimos? :) http://en.wikipedia.org/wiki/Deimos_(moon) OMG: It is named after Deimos, a figure representing dread in Greek Mythology. C'mon, Mars was really the God of War... His moons really show it. FearDread
Re: OT: phobos name
On Tuesday, 31 July 2012 at 14:32:01 UTC, Dejan Lekic wrote: That, on the other hand, was known to me. What I did not know, was the fear factor... Maybe the library should have been renamed to Deimos? :) What do you think where the term PHOBia came from?? That, for one, I missed it! Thanks!
Re: OT: phobos name
On Tuesday, 31 July 2012 at 14:32:01 UTC, Dejan Lekic wrote: That, on the other hand, was known to me. What I did not know, was the fear factor... Maybe the library should have been renamed to Deimos? :) What do you think where the term PHOBia came from?? And what about PHOBos? (PHOB Operating System) Just kidding. I stop here.
functions that do not sleep and recovery points
Hi, In Linux kernel programming, there are some parts that are not allowed to sleep (to be rescheduled). For example: interrupt handlers, softirqs and tasklets. Using functions that can sleep (for example: malloc, semaphores, regular mutexes - unlike spin_locks, etc.) is forbidden inside the above code entities. Currently, this is the responsibility of the programmer. I think that the compiler itself (the gcc) cannot enforce this as it cannot know for sure if a function may block (sleep) or no. But, the question is: - is there any mechanism in D (maybe @pure? @trusted? @notsleeping? or something similar) that could guarantee that a function cannot block? (and enforce that all the function called from inside that function are not-blocking too). More generally, to make such a property transitive and to enforce that? A bit off-topic, there is another question, this time concerning real-time programming: there are two basic strategies for error recovery: forward-recovery (that means, raising an exception and saving what can still be saved) and backward-recovery (that means, going back in time/code to a recovery point and trying to do the job again, maybe using an alternative algorithm). The forward-recovery is classic in C++ and D. The backward-recovery seems to not be so easy: exceptions can be used to detect such an error, but the language itself does not provides a way for establishing a recovery point (I think it might be seen as a program snapshot) to go back to it and then start again (while setting a flag to let the future know that an error occurred). Imagine: trying to compute using one fast algorithm but that diverge easily - failure. Then, roll back and try an alternative algorithm, that is more intensive but convergence is guaranteed etc. You have to know where to roll back. A simple goto will do it? Then, the second question is: - is there any mechanism in D to provide recovery points? Thank you.
just an idea (!! operator)
if needed, the operator !! (double exclamation mark) could be defined. it is just an idea, i do not have any specific use in mind. i encountered the operator in RT operating systems book: c!!e sends the message e along channel c c?x assigns to variable x the value from c maybe this could be integrated with the concurrency somehow or used in some other area.
Re: just an idea (!! operator)
On Wednesday, 11 July 2012 at 14:08:55 UTC, deadalnix wrote: On 11/07/2012 13:18, akaz wrote: So why do you do a proposal if this is not needed ? I did not ask for it, I only reminded that it is possible to define it if needed. It's merely a suggestion. I was reading a book and told myself: look, a nice operator! maybe could be useful if the D community knows about it!. Do you really see in my original post a request for defining it?
Re: why is string not implicit convertable to const(char*) ?
Well, then we're going to have to agree to disagree on that one. While some design decisions may have made more sense at the time they were made or the ultimate pros and cons may not have been clear at the time, I think that zero- terminated strings are one of the design decisions which was truly short- sighted and an enormous mistake all around, and all C/C++ programmers have had to pay for it ever since. - Jonathan M Davis I agree, despite the fact that it allows, in principle, creating strings as long as desired with constant cost (just one byte is sacrificed, instead of one, two, three, four etc. required to represent the length). Besides, using zero-terminated strings did not impose, in principle (forget about machine addressing issues) no upper bound on the length of a string. But, OTOH, it was also the only way to do it once the decision to not incorporate length in arrays (basically, under the assumption: an array is a pointer and nothing more) was made.
Garbage Collection Pitfall in C++ but not in D?
Hi, Reading about the C++11, I stumbled upon this: http://www2.research.att.com/~bs/C++0xFAQ.html#gc-abi Specifically (quote): int* p = new int; p+=10; // ... collector may run here ... p-=10; *p = 10;// can we be sure that the int is still there? How does the D garbage collector solves (answers) that? Thank you.
Re: Garbage Collection Pitfall in C++ but not in D?
If you are interested in D read this first: http://dlang.org/garbage.html You can find there e.g.: Do not add or subtract an offset to a pointer such that the result points outside of the bounds of the garbage collected object originally allocated. So `p+=10;` is already undefined behavior. Thank you, this clear the issue.
Re: Garbage Collection Pitfall in C++ but not in D?
On Friday, 6 July 2012 at 15:39:40 UTC, Alex Rønne Petersen wrote: On 06-07-2012 16:07, Denis Shelomovskij wrote: 06.07.2012 17:43, akaz пишет: Hi, Reading about the C++11, I stumbled upon this: I'll just add: Handling this case is basically impossible to do sanely. You can't really know what some pointer off the bounds of a managed memory region is based on. It could literally be based on any memory region in the entire program. You could do heuristics of course, but . . . Is not possible to make use of addRange() and removeRange() to block the GC over a specified time/range?
Re: Garbage Collection Pitfall in C++ but not in D?
On Friday, 6 July 2012 at 21:10:56 UTC, Simon wrote: On 06/07/2012 16:39, Alex Rønne Petersen wrote: On 06-07-2012 16:07, Denis Shelomovskij wrote: 06.07.2012 17:43, akaz пишет: Never mind what D says, even in C/C++ just doing the p += 10 is invalid. Creating a pointer that points at invalid memory is just as wrong as dereferencing it would be. Actually, p+10 could still be valid memory. OTOH, the other case that's given on the original page is this one: int* p = new int; int x = reinterpret_castint(p); // non-portable p=0; // ... collector may run here ... p = reinterpret_castint*(x); *p = 10;// can we be sure that the int is still there? So, the pointer could sometimes simply disappear temporarily, without becoming invalid (well, p==NULL is somewhat invalid, bt it could have been p=q). Just some allocated memory is no longer referenced for the time being and this could trigger the GC without protection (except disabling GC for the entire application). Won't some functions doing just what addRange() and removeRange() do solve that kind of problem (if necessary)? That means, forbidding the GC to scan some memory area for some time?
Re: Garbage Collection Pitfall in C++ but not in D?
Won't some functions doing just what addRange() and removeRange() do solve that kind of problem (if necessary)? That means, forbidding the GC to scan some memory area for some time? Like their C++11 counterparts: void declare_reachable(void* p); // the region of memory starting at p // (and allocated by some allocator // operation which remembers its size) // must not be collected templateclass T T* undeclare_reachable(T* p); void declare_no_pointers(char* p, size_t n); // p[0..n] holds no pointers void undeclare_no_pointers(char* p, size_t n);
Re: D2 Library Porters
On Tuesday, 3 July 2012 at 10:12:39 UTC, Iain Buclaw wrote: Hi, I'm going to be pushing gdc-4.8 package into debian this weekend (give about a fortnight for it to land in sid) - is Hi, I understand there will be no gdc-4.7 package, so this won't be available on Ubuntu 12.10 which (currently) seems to use the gcc 4.7.1 compiler, while proposing the gdc-4.6 package. Is this true? Any ideas about how this could be installed on Ubuntu 12.10? Should I drop Ubuntu in favor of Debian? Thanks
Re: Integer overflow and underflow semantics
Bumping this as we still need to make a decision about this. As recently as yesterday, someone on the GCC mailing list posted a complaint about an optimization pass that assumed undefined semantics for overflow. We need to have a stance about this, since GDC is going into mainline GCC soon. Just jumping into the bandwagon with several info: http://en.wikipedia.org/wiki/Therac Therac25 was a medicale machine that injured several people because: When input parameters are unverified or inconsistent, the treatment monitor task periodically runs a procedure that increments a counter This counter is used as a flag by the housekeeping task, indicating whether gun firing should be enabled or not However, as the counter is only 8 bits, it will overflow every 256 ticks, and the “flag” will temporarily indicate a zero condition! If the “set” command is given at that instant, inconsistencies are not checked, and unshielded high- energy radiation may result The case is known in the real-time operating systems programming. Does D throw an exception when an integral type (signed or unsigned) underflows or overflows? I am for defining this as the implicit behavior. Using a counter in the cyclical mode should be rather be explicitly invoked.
Re: Integer overflow and underflow semantics
I agree that throwing an exception could be a good feature to have, but it should *not* be the default. I want my systems code to run at full speed when I know what I'm doing. In the release version, yes. In the release version, array bound checking is disabled, too. But in the debug version?
Re: D dropped in favour of C# for PSP emulator
What started out as C with classes started acquiring this feature and that feature until the whole thing is just a haphazard heap of misfitting self-contradictory pieces, which requires an enormous amount of essentially-arbitrary rules just to clarify something as simple as, for example, automatic type conversions. Partially, this also can be told about D, too. It started as a cleaner C++ (I think) and grew up a bit complicated. Before arguing the contrary, please remember that C++ looks not complicated to Stroustrup. Maybe simply addressing the most bitter drawbacks and inconsistencies of C++ (and when I say that, I say notably syntax stupidities, *then* conceptual stupidities) was enough for, let's say, D_v1. Then, more, for D_v2. Maybe trying to address too much at once? My feeling (I tried to port and work something in D) is that it is a good language. But a complicate one and the learning time tends to be limited today. C caught in the first place for its simplicity. Java, too (hey, no pointers!). Annotations and other hell were added later, *after* the naguage got assimilated. C# too (hey! C++ made *simpler*!). Then it was C#2, 3, 4 etc. True, C++ grew up a complicated beast, but *gradually*. At the beginning, it was not. D does not have that gradualism in growing complicated. Not for its developers, but for its (mass) users.
Re: Jumping on the bandwagon - DDCPU-16
My latest issue with Java is the trend to add annotations instead of keywords, like @Override, or the new type annotations like @NotNull and so on. Its slowly going to annotation hell. It was never clear for me why use annotations instead of proper keywords. Yes, annotations are supposed to be a kind of meta-language but, then, why to make those part of a language? If they are intended to be part of the language, they should be proper keywords, no more, no less.
Re: Does D have too many features?
It's hard to grep for (since with is used in comments quite often), Try to search for with( or with\s(, that are less common in normal text. There is no tool (maybe the compiler could provide such a tool) to remove all comments? That way, you could do: cat file.d | tool | grep whatever
Re: Does D have too many features?
Sorry for my 2nd intervention on this thread. I recently ported some (not much) code from C to D. My impression was that D(2) tries to be too many things at once. I even considered porting to D(1) instead of D(2). What attracted me into the first place to D was it promise to be a better C (and a better C++), at least this is I saw it. However, it seems to have grown too complex to me. Yes, I understand that new, modern features should be provided by the language, but I do not like to be forced to use those. From my (limited) background, what I really liked in D: *the new type[n] and type* declaration syntax *the templates syntax (that's a biiig plus) *other things that I do not remember now, but they are plenty of them *the fact that constructors and destructors do not need renaming when class name changes (I hated that in C++ and Java), although I would have liked more special kewords like ctor() and dtor(), instead of this() and ~this(), but I can cope with that) What I did NOT like in D (is my impression): *the confusion between . and - operators (yes, I know the latter does not exist in D, is just for talking first here) for classes and structs and why classes are or are not pointers and why structs behave differently (or, at least, this is how I perceive it) and why not the pointer syntax is not used if they are pointers (well, references) and so on (yes, I am a bit dizzy, but is not entirely my fault; it's also D's). *the many @ annotations that is not clear if they are compulsory or not (and, if not, how to convince me to use them...) *the writing of the p[0..len] that you need to use when some other code (C code) passes you the pointer to data and the length (I just do not like it) *it is also my impression that you cannot declare int[] x=some_initialization as a static array with length filled in by compiler at the compile time, since the length is known? instead, x is interpreted as a dynamic array (which, also, I do not like that same syntax, or very similar, is used for both concepts). *the fact that the calling of a function bears no indication if you modify or not the passed variable (I much prefer the C-ish style of foo(a,b); where you *almost* know that b will be modified) Well, these are some. I feel that the right line is somewhere between D1 and D2. It is good that advanced, complex features are present in D, I just not want to be forced to use those when porting traditional C code. I expected to meet D and exclaim: wow! C++ done right! Instead, I feel like being forced to learn another, completely new paradigm language, like I would start with Lisp or something else. Remember: Within D, there is a much smaller and cleaner language struggling to get out.
Re: Does D have too many features?
On Saturday, 28 April 2012 at 19:58:03 UTC, foobar wrote: * di files - a library should encapsulate all the info required to use it. Java Jars, .Net assemblies and even old school; Pascal units all solved this long ago. I strongly support this.
Re: Mono-D 0.3.5
These are the flags used by DMD. If you can point Mono-D to gdmd instead of gdc it might work. gdmd is a wrapper around gdc that convert dmd flags to gdc flags. I cannot. GDMD toolchain is not even present among those in Mono-D. OTOH, I still do not know how to pass -lortp regular flag to the toolchain, in order to link with that libortp.so library.
Re: Mono-D 0.3.5
I need some help with Mono-D. I am on Linux 64 and I try to use both DMD 2.958 and GDC-4.6.3 However, I find difficult to: -set the Toolchain per project; apparently, only global option (Edit-Preferences-Other-D-Compiler Toolchains) exists -add libraries per project; again, only global option (Edit-Preferences-Other-D-Compiler Toolchains-Default Libraries exists) -the GDC toolchain keeps passing some unknown parameters to the compiler: for example, for the Debug ARguments-Executable, the passed arguments are: -g -debug $sources $libs $includes -od$objectsDirectory -of$exe of which all of -debug and -od$objectsDirectory and -of$exe are unknown to gdc (and similar for the others Build configurations) And finally: what should I put in that Default Libraries test box for DMD and for GDC toolchains to link with some C libraries that the gcc accepts as -lmediastreamer and -lortp? I should mention they are shared libraries: /usr/lib/libmediastreamer.so and /usr/lib/libortp.so, so there is no .a file that DMD could access. Compiling with gdc from the command line and adding -lmediastreamer -lortp works! Why Mono-D cannot be convinced to create such a simple compilation line? I use MonoDevelop 2.8.0.6.3 with (apparently) the latest Mono-D, ie. 0.3.5, installed according to: http://mono-d.alexanderbothe.com/?page_id=9 Thank you
Re: std.stream.File help required (and classes)
I am a bit lost between pointers
(s-x or (*s).x) and values (s.x). For structures there are
pointers,
for classes there are no pointers?
Yes.
Ali
And migrating from std.stream.File (which was a class) to
std.stdio.File (which is a structure) lost me completely.
Why, in fact, std.stream.File is a structure and not a class?
Citing: http://dlang.org/phobos/std_stdio.html
struct File;
Encapsulates a FILE*. Generally D does not attempt to provide
thin wrappers over equivalent functions in the C standard
library, but manipulating FILE* values directly is unsafe and
error-prone in many ways. The File type ensures safe
manipulation, automatic file closing, and a lot of convenience.
The underlying FILE* handle is maintained in a reference-counted
manner, such that as soon as the last File variable bound to a
given FILE* goes out of scope, the underlying FILE* is
automatically closed.
May I disable that reference counting?
I do not get how to use GC.addRange(). Can you, please, direct me
towards an example?
You seem to be right, the f and f.data variables are allocated
into my C code, so they are invisible to the garbage collector.
BUT!!! Is there any way to disable that garbage collector
straight from the beginning? Maybe a compiler flag?
I should also add that I allocated my structure with:
(init)
s.filedesc = cast(File*)GC.calloc(1,File.sizeof);
(open)
(*(s.filedesc)).open(*(cast(string*)arg),w+b);
but without success, since the MSF_State*
s=ms_new!(MSF_State)(1); line allocating the memory for s is
esentially a C library function (a wrapper around it):
extern(C){
//...
void* ortp_malloc(size_t sz);
T* ortp_new(T)(int count){
return cast(T*)ortp_malloc(T.sizeof*count);
}
alias ortp_new ms_new;
//...
}
so that allocation is not visible to the garbage collector.
My code has so many pointers because I took it from C, directly.
Many of those pointers are also imposed by the underlying (C)
library. I had no intention to extensively re-write my code, just
to port it.
Re: std.stream.File help required (and classes)
I should also add that I allocated my structure with: (init) s.filedesc = cast(File*)GC.calloc(1,File.sizeof); (open) (*(s.filedesc)).open(*(cast(string*)arg),w+b); OMG! That solution works! Except that I was making a silly mistake and thought that GC.alloc() prototype is similar to C's calloc (since it has two parameters). I fact, after writing: (init) s.filedesc = cast(File*)GC.calloc(File.sizeof*1); (open) (*(s.filedesc)).open(*(cast(string*)arg),w+b); now, my file remains open and I can write inside! (The data inside is not really what it should be, but that, at least, is a debugging problem, not a segfault one). Thank you once again!
Re: std.stream.File help required (and classes)
(The data inside is not really what it should be, but that, at least, is a debugging problem, not a segfault one). Just to let you know that I did it. I was writing the good data (as double), but it was my verification test that assumed it to be int... Now I corrected it and it works! Any way to mark this thread as solved?
std.stream.File help required (and classes)
Hi all,
I am trying to port some application based on a library called
mediastreamer2, part of linphone software.
The basic software component built on top of mediastreamer2 is
called a filter.
Basically, it is a C structure with parameters and some methods
(pointers to functions). Ammong the latter: a kind of constructor
(.init), a kind of destructor (.uninit), some setters and a sort
of run method (.process).
The run method is called by an independent thread (a time
ticker). It reads some queues, extract messages (packaged data)
from there and process this data.
Now, I implemented a filter which basically takes packaged data
(messages) from an input queue and *should* write this data into
a file.
This is built around a std.stream.File class.
Now, the questions:
1. why there is std.stdio.File, but also std.stream.File? This
gives a conflict and explicit names must then be used to avoid
conflict.
2. is the std.stream.File the correct choice here? Should I use
std.file instead? Then, why so many file classes (count
std.stdio.File too).
3. std.stream.File does not have, apparently, some
easy-to-interogate properties to know the name (path) and the
state of the associated file. Are there any?
4. the run method seems to lose knowledge about the file. The
file is opened in a setter and then it should remain seekable and
writeable. However, into the run method it appears as
unseekable and unwriteable. More, trying to access .toString()
property of the std.stream.File variable or to write some data
into the file triggers a segmentation fault error.
Here is the file msf_sinker_binaryfile.d, but if required, then
I will post other files too. I am not sure how to extract a
simpler test case.
//msf_sinker_binaryfile.d==
module msf_sinker_binaryfile;
import std.stream;
import std.stdio;
import mediastreamer2_layer;
import msf_commons;
const uint MSF_SINKER_BINARYFILE_OPEN =
MS_FILTER_METHOD!(byte)(cast(MSFilterId)MSFilterIdNew.MSF_SINKER_BINARYFILE_ID,0);
const uint MSF_SINKER_BINARYFILE_CLOSE =
MS_FILTER_METHOD_NO_ARG(cast(MSFilterId)MSFilterIdNew.MSF_SINKER_BINARYFILE_ID,1);
private struct _MSF_State{
__gshared std.stream.File filedesc; //file descriptor
};
private alias _MSF_State MSF_State;
private void msf_init(MSFilter* f){ //a constructor
printf(msf_binfile_init-start\n\n);
MSF_State* s=ms_new!(MSF_State)(1);
s.filedesc = new std.stream.File;
printf(s.filedesc=%p+\n,s.filedesc);
writef(s.filedesc.seekable=%b+\n,s.filedesc.seekable);
writef(s.filedesc.readable=%b+\n,s.filedesc.readable);
writef(s.filedesc.writeable=%b+\n,s.filedesc.writeable);
writef(s.filedesc.toString=%b+\n,s.filedesc.toString);
f.data=s;
printf(msf_binfile_init-stop\n\n);
}
private int msf_open(MSFilter* f, void* arg){ //a setter
printf(msf_binfile_open-start\n\n);
MSF_State* s=cast(MSF_State*)f.data;
ms_mutex_lock((f.lock));
printf(s.filedesc=%p+\n,s.filedesc);
writef(s.filedesc.seekable=%b+\n,s.filedesc.seekable);
writef(s.filedesc.readable=%b+\n,s.filedesc.readable);
writef(s.filedesc.writeable=%b+\n,s.filedesc.writeable);
writef(s.filedesc.toString=%b+\n,s.filedesc.toString);
s.filedesc.open(*(cast(string*)arg),FileMode.OutNew);
printf(s.filedesc=%p+\n,s.filedesc);
writef(s.filedesc.seekable=%b+\n,s.filedesc.seekable);
writef(s.filedesc.readable=%b+\n,s.filedesc.readable);
writef(s.filedesc.writeable=%b+\n,s.filedesc.writeable);
writef(s.filedesc.toString=%b+\n,s.filedesc.toString);
ms_mutex_unlock((f.lock));
printf(msf_binfile_open-stop\n\n);
return 0;
}
private void msf_process(MSFilter* f){ //a run() method
printf(msf_binfile_process-start\n\n);
MSF_State* s=cast(MSF_State*)f.data;
mblk_t* m;
while((m=ms_queue_get(f.inputs[0]))!=null){ //reading samples
from input
ms_mutex_lock((f.lock));
int len=cast(int)((m.b_wptr-m.b_rptr)); //length of message
data block
byte* p=cast(byte*)m.b_rptr;
/*printf(\n);
for(int idx=0; idxlen; idx++){
printf(d_data[%d]=%d\n,idx,d_data[idx]);
}
printf(\n);*/
//File filedesc;
//filedesc.open(newfile.bin,w+b);
Re: std.stream.File help required (and classes)
I should at that the __gshared attribute was added in distress, but changed nothing. With or without it, the program still crashes.
Re: std.stream.File help required (and classes)
Thank you. But why do I lose access to my std.stream.File file? Somehow, the variable gets unallocated, thus the file is closed back? With pointers of C it used to be so simple... variable remained allocated untel the corresponding free(). I do not quite grasp this (a bit) awkward mix between pointers and classes (references?). Sometimes is like C/C++, sometimes is like Java...
Re: std.stream.File help required (and classes)
std.file is more about files and directories, not file
contents. I've abandoned std.stream.File some time ago. I just
use std.stdio.File partly because stdio, stdout, and stderr are
of that type anyway. It works with ranges as well.
should be re-named std.folder, then, or std.filesystem. having
another file there is quite confusing. Oh, no! there is also
a... std.cstream!
std.stdio.File provides name() for the name and getFP() if you
want to access the underlying FILE*.
I understand that std.stdio.File is the newer approach. OK, I
will try to use that instead. BUT: what is the equivalent of
std.stream.File.writeBlock(const void* buffer, size_t size)? I
see there is a std.stdio.rawWrite(T)(in T[] buffer);
But, my data is: a (byte*) pointer and a length. How do I write
something like
std.stream.File.writeblock(cast(byte*)p,cast(int)len) using
std.stdio.File.rawWrite?
And why std.stream.File is not marked as deprecated if a better
(newer) alternative exists?
private void msf_init(MSFilter* f){ //a constructor
printf(msf_binfile_init-start\n\n);
MSF_State* s=ms_new!(MSF_State)(1);
s.filedesc = new std.stream.File;
[...]
f.data=s;
We are assuming that f never goes away and that f.data is not
assigned anything else, right? Otherwise the garbage collector
will destroy that MSF_State and reclaim its memory at an
indeterminate time. Is it possible that you use the MSF_State
object longer than you should, after it's lifetime ended? If
you did, the object would look usable for a while until the GC
collects it.
Yes, that should be the case. f is the mother structure (a
pointer towards a MSFilter structure) that should never disappear
and f.data should not be assigned somewhere else. I have several
other filters implemented using the same schema and they seem
to work quite well, except that they do not use files or...
classes (I still cannot grasp that fundamental thing when a class
instance is a variable and when it is a pointer; when is T x; and
when is T* x = new T(); or, when is T* x=(T*)calloc(1,sizeof(T));)
For the record, here is the main.d filter:
=main.d===
import std.stdio;
import core.thread;
import std.math;
import mediastreamer2_layer;
import msf_sourcer_sinusoid;
import msf_converter_double2int16_t;
import msf_sinker_binaryfile;
import msf_processor_split;
import msf_sinker_void;
int main(char[][] args)
{
MSTicker* ticker;
MSFilter* src_sinus;
MSFilter* cnv_dbl2int16_t;
MSFilter* snk_sndcrd;
MSFilter* snk_binfile;
MSFilter* prc_split1;
MSFilter* prc_split2;
MSFilter* snk_void;
printf(---START PROGRAM---\n);
ms_init();
src_sinus=ms_filter_new_from_desc(msf_sourcer_sinusoid_desc);
cnv_dbl2int16_t=ms_filter_new_from_desc(msf_converter_double2int16_t_desc);
snk_sndcrd=ms_snd_card_create_writer(ms_snd_card_manager_get_default_card(ms_snd_card_manager_get()));
snk_binfile=ms_filter_new_from_desc(msf_sinker_binaryfile_desc);
prc_split1=ms_filter_new_from_desc(msf_processor_split_desc);
prc_split2=ms_filter_new_from_desc(msf_processor_split_desc);
snk_void=ms_filter_new_from_desc(msf_sinker_void_desc);
double f0=1000.0;
ms_filter_call_method(src_sinus,MSF_SOURCER_SINUSOID_SET_FREQ,f0);
double fe=4000.0;
ms_filter_call_method(src_sinus,MSF_SOURCER_SINUSOID_SET_RATE,fe);
int fe_int=cast(int)round(fe);
ms_filter_call_method(snk_sndcrd,MS_FILTER_SET_SAMPLE_RATE,fe_int);
string numefisier=file_givenname.bin;
ms_filter_call_method(snk_binfile,MSF_SINKER_BINARYFILE_OPEN,cast(void*)numefisier);
ms_filter_link(src_sinus,0,prc_split1,0);
ms_filter_link(prc_split1,0,cnv_dbl2int16_t,0);
ms_filter_link(prc_split1,1,snk_binfile,0);
ms_filter_link(cnv_dbl2int16_t,0,snk_sndcrd,0);
ticker=ms_ticker_new();
ms_ticker_attach(ticker,src_sinus); //START
Thread.sleep(dur!(seconds)(3));
ms_ticker_detach(ticker,src_sinus); //STOP
ms_ticker_destroy(ticker);
ms_filter_call_method_noarg(snk_binfile,MSF_SINKER_BINARYFILE_CLOSE);
ms_exit();
printf(---STOP PROGRAM---\n);
return 0;
}
==
Finally: thank you very much for your help! I expected D to be a
sort of better C with *facultative* classes but I find it to be
quite... C#. Is my vision correct?
Re: std.stream.File help required (and classes)
OK, I converted into using the std.stdio.File. Without success,
the programs till crashes.
However, in the meantime:
A) why there is no parameter-less constructor for std.stdio.File?
I would like to have into my init function: s.filedesc=new
File() and, then, in my setter open method
s.filedesc.open(name,mode). Because I have no such constructor, I
am forced to have in the init: s.filedesc=null; and in the
open: s.filedesc=new File(name,mode). However, in that case,
what use for the std.stdio.File.open method? If the name and the
mode *must* be known at the construction time, then why ask those
once more for the std.stdio.File.open() method? I am forced to
open, first, a dummy file (in the constructor), only to be able
to call, later, the std.stdio.File.open() method with the correct
file name?
B) In my function:
private int msf_open(MSFilter* f, void* arg){ //a setter
printf(msf_binfile_open-start\n\n);
MSF_State* s=cast(MSF_State*)f.data;
ms_mutex_lock((f.lock));
s.filedesc = new File(*(cast(string*)arg),w+b);
printf(s.filedesc=%p+\n,s.filedesc);
writef(s.filedesc.isOpen=%b+\n,s.filedesc.isOpen);
writef(s.filedesc.name=%s+\n,s.filedesc.name);
writef(s.filedesc.size=%d+\n,s.filedesc.size);
ms_mutex_unlock((f.lock));
printf(msf_binfile_open-stop\n\n);
return 0;
}
can you tell me if the line s.filedesc=new
File(*(cast(string*)arg),w+b); PROPAGATES the change into
f.data? (recall that MSF_State* s=cast(MSF_State*)f.data;). I
should also force, at the end of the function (just before
return), something like: free(f.data); f.data=s; to propagate
this?
As dumb as it may seem: is my s variable in MSF_State*
s=cast(MSF_State*)f.data; a POINTER or a VALUE? I should write
s-filedesc? Or, maybe, (*s).filedesc? I am a bit lost between
pointers (s-x or (*s).x) and values (s.x). For structures there
are pointers, for classes there are no pointers?
Finally, the program crash on the same line, when trying to write
something in the file. Irony is that the s.filedesc.isOpen
shows... 1.
Here is my new msf_sinker_binaryfile.d file:
===msf_sinker_binaryfile.d==
module msf_sinker_binaryfile;
import std.stdio;
import mediastreamer2_layer;
import msf_commons;
const uint MSF_SINKER_BINARYFILE_OPEN =
MS_FILTER_METHOD!(byte)(cast(MSFilterId)MSFilterIdNew.MSF_SINKER_BINARYFILE_ID,0);
const uint MSF_SINKER_BINARYFILE_CLOSE =
MS_FILTER_METHOD_NO_ARG(cast(MSFilterId)MSFilterIdNew.MSF_SINKER_BINARYFILE_ID,1);
private struct _MSF_State{
File* filedesc; //file descriptor
};
private alias _MSF_State MSF_State;
private void msf_init(MSFilter* f){ //a constructor
printf(msf_binfile_init-start\n\n);
MSF_State* s=ms_new!(MSF_State)(1);
s.filedesc = null;
f.data=s;
printf(msf_binfile_init-stop\n\n);
}
private int msf_open(MSFilter* f, void* arg){ //a setter
printf(msf_binfile_open-start\n\n);
MSF_State* s=cast(MSF_State*)f.data;
ms_mutex_lock((f.lock));
s.filedesc = new File(*(cast(string*)arg),w+b);
printf(s.filedesc=%p+\n,s.filedesc);
writef(s.filedesc.isOpen=%b+\n,s.filedesc.isOpen);
writef(s.filedesc.name=%s+\n,s.filedesc.name);
writef(s.filedesc.size=%d+\n,s.filedesc.size);
ms_mutex_unlock((f.lock));
printf(msf_binfile_open-stop\n\n);
return 0;
}
private void msf_process(MSFilter* f){ //a run() method
printf(msf_binfile_process-start\n\n);
MSF_State* s=cast(MSF_State*)f.data;
mblk_t* m;
while((m=ms_queue_get(f.inputs[0]))!=null){ //reading samples
from input
ms_mutex_lock((f.lock));
int len=cast(int)((m.b_wptr-m.b_rptr)); //length of message
data block
byte* p=cast(byte*)m.b_rptr;
/*printf(\n);
for(int idx=0; idxlen; idx++){
printf(d_data[%d]=%d\n,idx,d_data[idx]);
}
printf(\n);*/
//File filedesc;
//filedesc.open(newfile.bin,w+b);
printf(s.filedesc=%p+\n,s.filedesc);
writef(s.filedesc.isOpen=%b+\n,s.filedesc.isOpen);
//writef(s.filedesc.name=%s+\n,s.filedesc.name);
//SEGFAULT
//writef(s.filedesc.size=%d+\n,s.filedesc.size);
//SEGFAULT
s.filedesc.writefln(This writes a string to the file.);
//SEGFAULT
//s.filedesc.writeBlock(p,len);
