Re: setjmp / longjmp
On Sat, 25 Apr 2015 23:25:13 +, Cassio Butrico wrote: > Hello everyone , first congratulations for the wonderful forum , I wish > someone could help me , I am writing a small basic interpreter in D and > I am with some difficulties. > > estoutentando manupular the setjmp / longjmp buffers , but the error , I > use windows 7 and the dmd 2067 , will be whose manipulate the buffers > save and return ? Excuse my english sucks. you shouldn't use setjmp/longjmp in D. use exceptions instead. something like this: instead of setjmp: try { doit } catch (MyException e) { process e } and instead of longjmp: throw new MyException(); signature.asc Description: PGP signature
Re: How to turn an inout(Object) into a string
On Sunday, April 26, 2015 05:09:30 Meta via Digitalmars-d-learn wrote: > On Sunday, 26 April 2015 at 04:52:36 UTC, Jonathan M Davis wrote: > > It's only undefined if mutation is involved, though I don't > > know if mutation is involved in this case or not > > I was thinking that a class can define an arbitrary toString() > that modifies it some of its member variables, which definitely > breaks const-correctness. > > class CustomToString > { > int n; > > override string toString() > { > n = 1; > > return "Uh oh"; > } > } > > void main() > { > import std.stdio; > > immutable c = new CustomToString(); > writeln(cast()c); > } Yes. That's legal and would be one reason to not just cast away const on an Object and call toString on it. It's just that in the example given, an immutable Object was constructed directly, and Object's toString isn't going to mutate anything. The question would be whether the call to writeln would (and it shouldn't). So, in the OP's code, I don't think that it's actually a problem, but in general, it could be, so it's ill-advised to cast away const - certainly, if you're going to, you need to be sure that mutation isn't going to occur to the object from which you cast away const. But I'd also argue that almost no code should be using Object for much of anything anyway. In theory, we're going to get rid of most of the functions on Object at some point here, at which point, Object won't be much more than a void* specific to class objects. And the implementations of those functions on Object are pretty useless anyway. - Jonathan M Davis
Re: Startup files for STM32F4xx
On 4/25/2015 10:02 PM, Timo Sintonen via Digitalmars-d-learn wrote: -Import mess. Phobos files import several other files. Some of them cannot be used. Work is going on to remove unnecessary imports and use scoped imports. It is important that imports for unittests are only in unittest blocks. -All functions have to be nogc. Active work is going on also in this area. The files should just be tried one by one to see if they can be compiled. It's important to note that most of the work occurring on these fronts is use-case driven. Not much is happening for the sake of completeness (except to some degree by Walter). So, your needs where they don't overlap with someone else's needs, might well take a long time to get done unless you do some of the driving. Even tackling the improvement of one or two api's helps drive towards completion.
Re: How to turn an inout(Object) into a string
On Sunday, 26 April 2015 at 04:52:36 UTC, Jonathan M Davis wrote: It's only undefined if mutation is involved, though I don't know if mutation is involved in this case or not I was thinking that a class can define an arbitrary toString() that modifies it some of its member variables, which definitely breaks const-correctness. class CustomToString { int n; override string toString() { n = 1; return "Uh oh"; } } void main() { import std.stdio; immutable c = new CustomToString(); writeln(cast()c); }
Re: Startup files for STM32F4xx
On Sunday, 26 April 2015 at 00:52:56 UTC, Mike wrote: On Saturday, 25 April 2015 at 16:32:50 UTC, Timo Sintonen wrote: I think there's a few gems that can be cherry-picked out of Phobos, especially for metaprogramming: std.traits std.typecons std.typetuple There are also a couple things in these libraries that might be useful for programming in general: std.conv std.string std.array Mike Yes. This has been in my plans but I have not hurried because: -Import mess. Phobos files import several other files. Some of them cannot be used. Work is going on to remove unnecessary imports and use scoped imports. It is important that imports for unittests are only in unittest blocks. -All functions have to be nogc. Active work is going on also in this area. The files should just be tried one by one to see if they can be compiled.
Re: How to turn an inout(Object) into a string
On Sunday, April 26, 2015 03:51:25 Meta via Digitalmars-d-learn wrote: > On Sunday, 26 April 2015 at 03:48:00 UTC, tcak wrote: > > On Sunday, 26 April 2015 at 03:09:17 UTC, Meta wrote: > >> The following code spits out pages of error messages, and it's > >> driving me insane. I know that Object.toString only has a > >> mutable variant, so how am I supposed to use writeln, > >> toString, etc. with an inout, const, or immutable object? > >> > >> void main(inout string[] args) > >> { > >>import std.stdio; > >> > >>immutable(Object) o = new immutable Object(); > >>//Compile error: template instance > >>//std.format.formatGeneric!( > >>//LockingTextWriter, immutable(Object), > >>//char) > >>//error instantiating > >>writeln(o); > >> } > > > > writeln( cast(Object)o ); > > > > Tada!! > > Also undefined behaviour, AFAIK. It's only undefined if mutation is involved, though I don't know if mutation is involved in this case or not (I wouldn't think so, but I don't know), and in general, you definitely shouldn't be casting away const. The real problem here is likely that toString on Object isn't const, and we can't make it const. The fix for that which was decided upon was to remove toString, toHash, opCmp, and opEquals from Object altogether, since we have proper templates in D and don't really need to put any of those on Object directly (in which case printing out a plain Object wouldn't work at all anyway), but there's a fair bit to do before those changes can be made, and unfortunately, not much of the work for it has been done yet. https://issues.dlang.org/show_bug.cgi?id=9769 https://issues.dlang.org/show_bug.cgi?id=9770 https://issues.dlang.org/show_bug.cgi?id=9771 https://issues.dlang.org/show_bug.cgi?id=9772 - Jonathan M Davis
Re: How to turn an inout(Object) into a string
On Sunday, 26 April 2015 at 03:48:00 UTC, tcak wrote: On Sunday, 26 April 2015 at 03:09:17 UTC, Meta wrote: The following code spits out pages of error messages, and it's driving me insane. I know that Object.toString only has a mutable variant, so how am I supposed to use writeln, toString, etc. with an inout, const, or immutable object? void main(inout string[] args) { import std.stdio; immutable(Object) o = new immutable Object(); //Compile error: template instance //std.format.formatGeneric!( //LockingTextWriter, immutable(Object), //char) //error instantiating writeln(o); } writeln( cast(Object)o ); Tada!! Also undefined behaviour, AFAIK.
Re: How to turn an inout(Object) into a string
On Sunday, 26 April 2015 at 03:09:17 UTC, Meta wrote: The following code spits out pages of error messages, and it's driving me insane. I know that Object.toString only has a mutable variant, so how am I supposed to use writeln, toString, etc. with an inout, const, or immutable object? void main(inout string[] args) { import std.stdio; immutable(Object) o = new immutable Object(); //Compile error: template instance //std.format.formatGeneric!( //LockingTextWriter, immutable(Object), //char) //error instantiating writeln(o); } writeln( cast(Object)o ); Tada!!
How to turn an inout(Object) into a string
The following code spits out pages of error messages, and it's driving me insane. I know that Object.toString only has a mutable variant, so how am I supposed to use writeln, toString, etc. with an inout, const, or immutable object? void main(inout string[] args) { import std.stdio; immutable(Object) o = new immutable Object(); //Compile error: template instance //std.format.formatGeneric!( //LockingTextWriter, immutable(Object), //char) //error instantiating writeln(o); }
Re: Microcontroller startup file - supported devices wish-list
On 26/04/2015 5:53 a.m., Jens Bauer wrote: As I'm impressed with the interest in the startup-files I've made so far, I'd like to add support for more devices. In order to do so, I'd like to ask on this forum, which devices you would be interested in. Please list specific device names/numbers if possible, but device families are of course also welcome. -If you have a URL to existing C startup files, please provide this as well, it will ease my job and thus make the files available to you faster. In other words: If a URL is provided to existing C-libraries, it will have higher priority than a wish without URLs. Currently I have startup files for the following devices: STM32F401 STM32F405 STM32F407 STM32F411 STM32F415 STM32F417 STM32F427 STM32F429 STM32F437 STM32F439 LPC81x LPC82x LPC110x LPC1125 LPC11axx LPC11cxx LPC11exx LPC11lvxx LPC11uxx LPC12xx LPC1343 LPC1347 LPC175x + LPC176x LPC177x + LPC178x LPC18xx LPC43xx_m4, LPC43xx_m0 I'm planning on adding more STM32 devices. including Cortex-M0, Cortex-M0+ and Cortex-M3 devices, but please let me know if there are specific devices you want added first. Try to keep posts to this particular thread short and to the point; it'll give a better overview. Move this over to e.g. D's wiki (or Github repo's) and post a link into d.D news group. Preferably with links to each startup file in version control.
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 16:32:50 UTC, Timo Sintonen wrote: On Saturday, 25 April 2015 at 11:56:55 UTC, Martin Nowak wrote: I have not yet needed anything from libc/phobos in my programs. I think there's a few gems that can be cherry-picked out of Phobos, especially for metaprogramming: std.traits std.typecons std.typetuple There are also a couple things in these libraries that might be useful for programming in general: std.conv std.string std.array Mike
@disable assignment of [] literal?
Consider the following code: struct ArrayWrapper(T) { T t; this(T t) { assert(t !is null); } @disable this(typeof(null)); typeof(this) opAssign(T val) { assert(t !is null); this.t = val; return this; } @disable typeof(this) opAssign(typeof(null)); @disable typeof(this) opAssign(typeof([])); } void main() { //This is caught at compile time ArrayWrapper!(int[]) a = null; //This throwns a runtime error ArrayWrapper!(int[]) b = []; } That's fine, though, we can just add `@disable this(typeof([]))`. But wait, that doesn't work. The @disable'd constructor is ignored and it takes the this(T t) constructor instead. I have no idea why, as this(typeof(void[])) should be more specialized than this(int[]) when called with `[]`, but okay. This isn't the only case that this doesn't work, either: ArrayWrapper!(int[]) b; //Caught at compile time, as expected b = null; //Throws a runtime error b = []; So in both cases, the compiler ignores the @disable'd constructor and opAssign when called with `[]`. I tried changing them both to be templated, which made the "normal" constructor and opAssign less specialized than the @disable'd ones. Fortunately, this strategy worked... sort of: struct ArrayWrapper(T) { T t; this(U)(U u) { assert(u !is null); } @disable this(typeof(null)); @disable this(typeof([])); typeof(this) opAssign(U)(u val) { assert(u !is null); this.t = val; return this; } @disable typeof(this) opAssign(typeof(null)); @disable typeof(this) opAssign(typeof([])); } void main() { //This is caught at compile time ArrayWrapper!(int[]) a = null; //This is caught at compile time too now. Awesome! ArrayWrapper!(int[]) b = []; ArrayWrapper!(int[]) a; //Caught at compile time a = null; ArrayWrapper!(int[]) b; //Now also caught at compile time b = []; } My hopes were instantly dashed when I tried the following: //Compile error. Okay... ArrayWrapper!(void[]) c = []; //This is also a compile error c = cast(void[])[1, 2, 3]; And the same for opAssign: ArrayWrapper!(void[]) c; //Compile error c = []; //Also a compile error c = cast(void[])[1, 2, 3]; So as you can see, it's more or less impossible to completely catch the assignment of [] to an array at compile time, even though it should be perfectly feasible. Is there any way I can accomplish this without making ArrayWrapper unusable for void[], or is a runtime check the best I can do?
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 19:33:05 UTC, Johannes Pfau wrote: volatileLoad is not in gdc yet. I've written the code some months ago but I need to update it and then it needs to be reviewed. It's officially in 2.067.0 for anyone who's wondering. Volatile!T: http://dpaste.dzfl.pl/dd7fa4c3d42b Volatile!size_t value; value += 1; assert(value == 1); Register wrapper: http://dpaste.dzfl.pl/3e6314714541 Register definition: enum Level : ubyte { low = 0, high = 1 } enum fields = [ Field("PIN0", 0, 0, true, "Level", Access.readWrite), Field("PIN1", 1, 1, true, "Level", Access.readWrite), Field("TEST", 2, 4, false, "ubyte", Access.readWrite)]; mixin(generateRegisterType!ubyte("PORT", fields)); pragma(address, 0x25) extern __gshared PORTRegister PORTB; Usage: auto b = PORTB.load(); PORTB.toggle!"PIN0"; PORTB.PIN0 = Level.low; writeln(PORTB.PIN0); PORTB.TEST = 0b000; That's some nice code! and really leveraging D to great effect. I know that Volatile!(T) took some engineering to get right, so it would be nice to have that as an "official" type IMO. The remaining problem is performance. (With optimization the generated code is as good as equivalent C code. However, we need to avoid size overhead: e.g. struct initializers and the opX functions shouldn't generate functions in the executable, though tha can be fixed with the linker) I'm not sure I follow how the linker can solve this. Could you elaborate? Mike
Private alias escaping -- is this a bug?
I ran into this infuriatingly confusing situation just now: static assert(is(typeof(Parent.init.new Child) == Parent.Child)); // fine alias P = Parent; alias T = Parent.Child; static assert(is(typeof(P.init.new T) == T)); // nope! Wat??? After much confusion, I finally discovered this in my class: class Parent { class Child { } mixin MyMixin; } mixin Template MyMixin() { private alias T = ...; // the culprit! } Should the private alias be able to escape? Is this a bug or expected behavior? Also, is there a nice way to create template-level aliases in mixin templates that don't leak into the class? MyMixin generates multiple functions that all use T.
Re: Private alias escaping -- is this a bug?
On Saturday, 25 April 2015 at 23:51:05 UTC, rcorre wrote: I ran into this infuriatingly confusing situation just now: static assert(is(typeof(Parent.init.new Child) == Parent.Child)); // fine alias P = Parent; alias T = Parent.Child; static assert(is(typeof(P.init.new T) == T)); // nope! Wat??? After much confusion, I finally discovered this in my class: class Parent { class Child { } mixin MyMixin; } mixin Template MyMixin() { private alias T = ...; // the culprit! } Should the private alias be able to escape? Is this a bug or expected behavior? Also, is there a nice way to create template-level aliases in mixin templates that don't leak into the class? MyMixin generates multiple functions that all use T. You could namespace them in a sense by defining a nested struct that contains the aliases.
setjmp / longjmp
Hello everyone , first congratulations for the wonderful forum , I wish someone could help me , I am writing a small basic interpreter in D and I am with some difficulties. estoutentando manupular the setjmp / longjmp buffers , but the error , I use windows 7 and the dmd 2067 , will be whose manipulate the buffers save and return ? Excuse my english sucks.
Re: BigInt to binary
On 04/25/2015 01:23 PM, Dennis Ritchie wrote: which section should apply similar requests? https://issues.dlang.org/ After clicking "File and Issue": Component: Phobos Severity: Enhancement Ali
Re: BigInt to binary
On Saturday, 25 April 2015 at 18:58:50 UTC, Marc Schütz wrote: BigInt only supports %d, %x, %X and %s: http://dlang.org/phobos/std_bigint.html#.BigInt.toString The missing %o and %b were probably an oversight, feel free to file an enhancement request or submit a PR. All right. I will file a request. Just tell me, please, in which section should apply similar requests? https://issues.dlang.org/
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 19:33:05 UTC, Johannes Pfau wrote: Am Sat, 25 Apr 2015 18:31:45 + schrieb "Jens Bauer" : I don't want to start another volatile discussion, but to me it seems an attribute would not be a bad idea. -And for completeness... read-only, write-only, read/write and perhaps even 'prohibited access'. I recall that something was marked prohibited in some way in a library once; I forgot how they did it, though. volatileLoad is not in gdc yet. I've written the code some months ago but I need to update it and then it needs to be reviewed. I might be able to do a few tests, but I don't feel qualified for code reviewing at this time. ;) Always using volatileLoad/Store is annoying. The solution is to write a wrapper: I was hoping for something in that direction. Volatile!size_t value; {snip} Usage: auto b = PORTB.load(); PORTB.toggle!"PIN0"; PORTB.PIN0 = Level.low; writeln(PORTB.PIN0); PORTB.TEST = 0b000; It is much more convenient to use it this way, yes; I think it will cover most needs. Regarding performance: If a real high time-critical speed is needed, people would probably use assembly code anyway. ;)
Re: Startup files for STM32F4xx
Am Sat, 25 Apr 2015 18:31:45 + schrieb "Jens Bauer" : > On Saturday, 25 April 2015 at 17:58:59 UTC, Timo Sintonen wrote: > > On Saturday, 25 April 2015 at 17:04:18 UTC, Jens Bauer wrote: > > > >> I think volatileLoad and volatileStore are intended for this > >> (please correct me if my understanding is wrong). > >> > > Yes. Actually I am not sure whether they already exist in gdc > > or not. > > > > Try to write for example > > regs.cmdr |= 0x20 > > with these functions and guess how many users will move to > > another language. > > Ah, I get the point now. :) > > I don't want to start another volatile discussion, but to me it > seems an attribute would not be a bad idea. > -And for completeness... read-only, write-only, read/write and > perhaps even 'prohibited access'. I recall that something was > marked prohibited in some way in a library once; I forgot how > they did it, though. volatileLoad is not in gdc yet. I've written the code some months ago but I need to update it and then it needs to be reviewed. Always using volatileLoad/Store is annoying. The solution is to write a wrapper: Volatile!T: http://dpaste.dzfl.pl/dd7fa4c3d42b Volatile!size_t value; value += 1; assert(value == 1); Register wrapper: http://dpaste.dzfl.pl/3e6314714541 Register definition: enum Level : ubyte { low = 0, high = 1 } enum fields = [ Field("PIN0", 0, 0, true, "Level", Access.readWrite), Field("PIN1", 1, 1, true, "Level", Access.readWrite), Field("TEST", 2, 4, false, "ubyte", Access.readWrite)]; mixin(generateRegisterType!ubyte("PORT", fields)); pragma(address, 0x25) extern __gshared PORTRegister PORTB; Usage: auto b = PORTB.load(); PORTB.toggle!"PIN0"; PORTB.PIN0 = Level.low; writeln(PORTB.PIN0); PORTB.TEST = 0b000; The remaining problem is performance. (With optimization the generated code is as good as equivalent C code. However, we need to avoid size overhead: e.g. struct initializers and the opX functions shouldn't generate functions in the executable, though tha can be fixed with the linker)
Re: BigInt to binary
On Saturday, 25 April 2015 at 13:13:10 UTC, Dennis Ritchie wrote: Hi, Is there a way to apply a function "format" with BigInt? - import std.stdio, std.bigint, std.string; void main() { BigInt n = -10; string s = format("%b", n); // error writeln(s); } BigInt only supports %d, %x, %X and %s: http://dlang.org/phobos/std_bigint.html#.BigInt.toString The missing %o and %b were probably an oversight, feel free to file an enhancement request or submit a PR.
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 17:58:59 UTC, Timo Sintonen wrote: On Saturday, 25 April 2015 at 17:04:18 UTC, Jens Bauer wrote: I think volatileLoad and volatileStore are intended for this (please correct me if my understanding is wrong). Yes. Actually I am not sure whether they already exist in gdc or not. Try to write for example regs.cmdr |= 0x20 with these functions and guess how many users will move to another language. Ah, I get the point now. :) I don't want to start another volatile discussion, but to me it seems an attribute would not be a bad idea. -And for completeness... read-only, write-only, read/write and perhaps even 'prohibited access'. I recall that something was marked prohibited in some way in a library once; I forgot how they did it, though.
Re: std.json questions
On Saturday, 25 April 2015 at 09:56:25 UTC, tired_eyes wrote: I think this is ugly and clunky approach, what is the beautiful one? What you clearly need is a serializer: look at these: http://wiki.dlang.org/Libraries_and_Frameworks#Serialization and also: https://github.com/search?utf8=✓&q=serializer+language%3AD&type=Repositories&ref=searchresults some of them might have an API to save load an object or a struct in a single call.
Re: std.json questions
On Saturday, 25 April 2015 at 09:56:25 UTC, tired_eyes wrote: A brief look at code.dlang.org gives us 7 (!) additional JSON libraries. Keeping in mind that D community isn't so huge, I think I'm not the only person struggling with std.json. Are there any plans on upgrading it? See http://wiki.dlang.org/Review_Queue. std.data.json is the proposed replacement for the current phobos json implementation. There is also supposedly std.serialization in the works.
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 17:04:18 UTC, Jens Bauer wrote: I think volatileLoad and volatileStore are intended for this (please correct me if my understanding is wrong). Yes. Actually I am not sure whether they already exist in gdc or not. Try to write for example regs.cmdr |= 0x20 with these functions and guess how many users will move to another language.
Microcontroller startup file - supported devices wish-list
As I'm impressed with the interest in the startup-files I've made so far, I'd like to add support for more devices. In order to do so, I'd like to ask on this forum, which devices you would be interested in. Please list specific device names/numbers if possible, but device families are of course also welcome. -If you have a URL to existing C startup files, please provide this as well, it will ease my job and thus make the files available to you faster. In other words: If a URL is provided to existing C-libraries, it will have higher priority than a wish without URLs. Currently I have startup files for the following devices: STM32F401 STM32F405 STM32F407 STM32F411 STM32F415 STM32F417 STM32F427 STM32F429 STM32F437 STM32F439 LPC81x LPC82x LPC110x LPC1125 LPC11axx LPC11cxx LPC11exx LPC11lvxx LPC11uxx LPC12xx LPC1343 LPC1347 LPC175x + LPC176x LPC177x + LPC178x LPC18xx LPC43xx_m4, LPC43xx_m0 I'm planning on adding more STM32 devices. including Cortex-M0, Cortex-M0+ and Cortex-M3 devices, but please let me know if there are specific devices you want added first. Try to keep posts to this particular thread short and to the point; it'll give a better overview.
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 17:11:22 UTC, Johannes Pfau wrote: Am Sat, 25 Apr 2015 11:38:45 + schrieb "Martin Nowak" : On Saturday, 25 April 2015 at 05:07:04 UTC, Jens Bauer wrote: > > import mcu.stm32f439.all I think that belongs in the makefile/dub.json as -version=STM32F439. Then you could simply import mcu.gpio or mcu.spi. We need a better / clever generic approach to solve 'board configuration' issues. Here version blocks work but you might also want to specify other configuration options (clock speed if static, ...) and we don't have -D to define constants. I actually attempted to use version on the exception vector list, but as you cannot do this ... @isr_vector VectorFunc[] g_pfnVectors = [ cast(VectorFunc)&_stack, &Reset_Handler, version(USB){ &USBActivity_IRQHandler, } version(CAN){ &CANActivity_IRQHandler, } ]; ... I ditched the idea. There might be a good way for doing this, so that the number of startup files can be reduced, and perhaps allow for increased convenience. One thing that's tedious, is when the vendor replaces a single handler in a later device implementation. I can't seem to make a chain of weak aliases, eg.. SPI0_Interrupt() defaults to defaultExceptionHandler() SPI_Interrupt() defaults to SPI0_Interrupt() implementing SPI_Interrupt() would then automatically use this in the exception vector, but if also implementing SPI0_Interrupt(), thene SPI0_Interrupt() would have higher priority and SPI_Interrupt() should be discarded. If neither SPI0_Interrupt() nor SPI_Interrupt() is implemented, then they would fallback to defaultExceptionHandler(). -I could not get such an 'alias-chain' working; perhaps it's just because I got confused, perhaps it's because the compiler does not support it. - I don't know yet. ;) If an alias-chain was possible, I think the startup files could become fairly pretty, and there wouldn't be problems with using the wrong handler name on chips where the vendors decided to rename the handler functions within one chip-family (I won't tell anyone who you are, NXP - I promise!).
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 11:50:19 UTC, Martin Nowak wrote: On Saturday, 25 April 2015 at 07:31:45 UTC, Jens Bauer wrote: Static constructors are possible if you strip down ModuleInfo (requires compiler hacking). You should care about that stuff last. It's way more important to make things work without dynamic memory allocation first. I agree and thanks for reminding me; I don't want to lose my focus. ;) That means 'new' and 'delete' / 'malloc' and 'free' must be able to handle multiple RAM locations (because there's also external SRAM and external SDRAM). IIRC then the C/C++ malloc would simply can your sbrk Heh, I didn't know about sbrk before I almost finished writing mine. This resulted in that mine can be used side-by-side with the standard malloc. (I named mine m_malloc and m_free). implementation, so it only supports a single heap, which should be the external if available. In C++, it's possible to override new and delete on a per-class basis, I'd expect that this is possible in D as well, is this correct ? -If it is, then I think there's no problem, because then the class can handle special cases, when it knows it's working with the DMA. Allocation could default to SDRAM if SDRAM exists; then external SRAM, then CCMRAM and finally fallback to Local on-chip SRAM. (Note: any external RAM needs to be initialized by the microcontroller's firmware, before the external RAM can be used, I do not know if that could be a problem with the linker-generated static constructors).
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 11:38:46 UTC, Martin Nowak wrote: On Saturday, 25 April 2015 at 05:07:04 UTC, Jens Bauer wrote: I hope to find a good way to use import for microcontroller libraries, so it'll be easy for everyone. I'm thinking about something like ... import mcu.stm32f439.all I think that belongs in the makefile/dub.json as -version=STM32F439. Then you could simply import mcu.gpio or mcu.spi. I've had the same thoughts myself, but I do not like forcing the user to modify the Makefile. (I currently have a -complicated- Makefile system, which does not require the Makefile to be modified) I don't want to require the user to edit the linker-script either (though we're not really speaking about that; my point is that I want it to be simple and easy for D-newcomers; whether D is their first or 2nd language). It could be a good solution to use version(Ethernet), version(SPI5), version(LTDC) and version(SAI2) ... to enable interrupt handlers in the modules. -But as I have not really worked with modules yet, there are still a lot of unknowns - I'm only guessing here.
Re: Startup files for STM32F4xx
Am Sat, 25 Apr 2015 11:38:45 + schrieb "Martin Nowak" : > On Saturday, 25 April 2015 at 05:07:04 UTC, Jens Bauer wrote: > > I hope to find a good way to use import for microcontroller > > libraries, so it'll be easy for everyone. I'm thinking about > > something like ... > > > > import mcu.stm32f439.all > > I think that belongs in the makefile/dub.json as > -version=STM32F439. > Then you could simply import mcu.gpio or mcu.spi. We need a better / clever generic approach to solve 'board configuration' issues. Here version blocks work but you might also want to specify other configuration options (clock speed if static, ...) and we don't have -D to define constants. I think we could use 'reverse' imports but I'm not sure if it's a horrible hack or a great idea: When compiling library code: // board.di (Only 'runtime' config variables) - module board.config; __gshared const int configA; __gshared const int configB; - //library code: lib.d - import board.config; void doFoo() // Function => runtime value { auto a = configA; } void templateFoo()() // Template => ctfe value { auto b = ctfeConfigA; //This value is not in .di => error if //template is instantiated in the library } - gdc lib.d -Ipath/for/board.di -o lib.o User code: // board.d ('runtime' + 'ctfe' config variables) - module board.config; __gshared const int configA = 42; __gshared const int configB = 42; enum ctfeConfigA = 42; - gdc lib.o board.d
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 16:32:50 UTC, Timo Sintonen wrote: On Saturday, 25 April 2015 at 11:56:55 UTC, Martin Nowak wrote: You better dismiss the idea of using druntime/phobos. The minimum runtime I have made does fit in 64k rom/ 64k ram, which all STM32F4 devices have. With some work it may even fit to the smaller memory of STM32F0. I definitely think it's possible to do this, as I've already been using Timo's minlibd. -But I'm thinking of something even simpler: No file system support at all - and a few other things when I come across them. ;) I have not yet needed anything from libc/phobos in my programs. I think that I should focus on making it possible to ... 1: Use classes (I find this very important) 2: Strings 3: Associative arrays Perhaps a few other important features will be added to the list (I do not know the D language that well yet, so there is most likely something else)
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 16:28:24 UTC, Timo Sintonen wrote: My work is based on the feature that a shared variable is marked as volatile in gcc. This feature is buggy and should not be used in the future. I think volatileLoad and volatileStore are intended for this (please correct me if my understanding is wrong). The official way is to use library functions to access registers but I think this results to horrible looking code. Are these library functions the above mentioned volatileLoad / volatileStore ? Someone might then make an sample driver and after discussion we all could start write drivers the same way. I Agree. It would just be plain typing-till-your-fingers-hurt after that. ;)
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 11:34:58 UTC, Martin Nowak wrote: You can very well abstract an SPI, just need to have an abstraction for pins. http://developer.mbed.org/handbook/SPI Considering all the problems involved, I will not be doing any abstraction. What I will provide, is a set of templates and startup-files generated from those templates. The inital LPC17xx and STM32F4xx repositories will be short-lived. I'll be creating a single repository for all startup-files, which also means I will make a tree that looks something like this: mcu/ stm32/ lpc/ kinetis/ tivo/ ... ... common/ Inside each device folder, I'll probably make space for hardware definitions, but I will not provide any classes and further convenience. I'll, however, try to keep things fairly consistent, and in some cases I'll be so annoying that I'll rename the names of the interrupt vectors that the vendors provide. ;)
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 11:56:55 UTC, Martin Nowak wrote: You better dismiss the idea of using druntime/phobos. They are not optimized for code size and contain a lot of stuff that'll never work. You can replace the core.stdc headers with bindings for nanolib, but again it's not necessary for doing useful stuff and should be done later. The minimum runtime I have made does fit in 64k rom/ 64k ram, which all STM32F4 devices have. With some work it may even fit to the smaller memory of STM32F0. I have not yet needed anything from libc/phobos in my programs.
Re: std.json questions
"tired_eyes" writes: > > First issue: what is the proper ("idiomatic") way to conver JSONValue > to the proper types? > > Second: what is the proper way of handling boolean values in JSON (how > to convert JSON_TYPE.TRUE and JSON_TYPE.FALSE to bool)? > > Righ now I'm doing is something like this: > > string data = readText("file.json"); > JSONValue[string] parsedData = parseJSON(data).object; > JSONValue[] etities = stateData["entities"].array; > > foreach(e; entities) { > int x = to!int(e["x"].integer); > int y = to!int(e["y"].integer); > string texture = stripExtension(e["texture"].str); > > auto isControllable = "isControllable" in e; > > if (isControllable !is null) { > if (e["isControllable"].type == JSON_TYPE.TRUE) { > isControllable = true; > } else { > isControllable = false; > } > } > } > > I think this is ugly and clunky approach, what is the beautiful one? > > A brief look at code.dlang.org gives us 7 (!) additional JSON > libraries. Keeping in mind that D community isn't so huge, I think I'm > not the only person struggling with std.json. Are there any plans on > upgrading it? Hi and welcome to D land. I see discussions on how std.json needs to be upgraded. And it is not well documented. I tried to progressively simplify the code that was posted to show what can be done, but keeping the same spirit. Not necessarily beautiful, but less verbose code. I did not see a simpler way to deal with bools in the std.json code. Others here are experts on idiomatic D, they may show something much better. // First , make it work and show all types void f1() { string data = readText("file.json"); JSONValue parsedData = parseJSON(data); JSONValue entities = parsedData["entities"]; foreach(size_t index, e; entities) { long x = e["x"].integer; long y = e["y"].integer; string texture = stripExtension(e["texture"].str); bool isControllable = false; if ("isControllable" in e) { if (e["isControllable"].type == JSON_TYPE.TRUE) { isControllable = true; } else { isControllable = false; } } writefln("x %d y %d texture %s isControllable %s", x, y, texture, isControllable); } } // Next, let compiler figure types for us void f2() { auto data = readText("file.json"); auto parsedData = parseJSON(data); auto entities = parsedData["entities"]; foreach(size_t _, e; entities) { auto x = e["x"].integer; auto y = e["y"].integer; auto texture = stripExtension(e["texture"].str); bool isControllable = false; if ("isControllable" in e) { isControllable = e["isControllable"].type == JSON_TYPE.TRUE; } writefln("x %d y %d texture %s isControllable %s", x, y, texture, isControllable); } } // A little simpler isControllable. void f3() { auto parsedData = readText("file.json").parseJSON; foreach(size_t _, e; parsedData["entities"]) { auto x = e["x"].integer; auto y = e["y"].integer; auto texture = stripExtension(e["texture"].str); auto isControllable = "isControllable" in e && e["isControllable"].type == JSON_TYPE.TRUE; writefln("x %d y %d texture %s isControllable %s", x, y, texture, isControllable); } }
Re: Startup files for STM32F4xx
Before you start to write device drivers I remind you that it is not possible to just write and read the peripheral registers via pointers. The compiler will do optimizations like omit reads and writes or reorder them. My very simple uart driver is here: https://bitbucket.org/timosi/minlibd/src/15e88941c534a19e753fa0eebcd053b17392b7ad/tools/main/uart.d?at=default and gpio driver is here: https://bitbucket.org/timosi/minlibd/src/15e88941c534a19e753fa0eebcd053b17392b7ad/tools/main/gpio.d?at=default My work is based on the feature that a shared variable is marked as volatile in gcc. This feature is buggy and should not be used in the future. The official way is to use library functions to access registers but I think this results to horrible looking code. This issue has currently stopped my work with device drivers. I would like to hear from compiler developers what is the idiomatic D way to do this. Someone might then make an sample driver and after discussion we all could start write drivers the same way.
Re: o!(const(T)) parameter.
It works when you exclude the recursive alias this: static if(!is(T == const)) alias constify this; Your original program crashes the compiler, which is always a bug. I filed an issue: https://issues.dlang.org/show_bug.cgi?id=14499 Thank you, very much.
Re: o!(const(T)) parameter.
On Saturday, 25 April 2015 at 14:52:45 UTC, sclytrack wrote: I want a function with parameter o!(const(Form)) to accept both o!(Form) and o!(immutable(Form)) Is there a way to do it? import std.stdio; import std.traits; class Form { int number = 10; } struct o(T) { T data; this(T data) { this.data = data; } o!(const(Unqual!(T))) constify() const { return o!(const(Unqual!(T)))(data); } alias constify this; } void hello(o!(const(Form)) frm) { writeln(frm.data.number); writeln(typeof(frm.data).stringof); } void main() { writeln("This application works nicely"); auto frm = o!(Form) (new Form()); // auto ifrm = o!(immutable(Form)) (new immutable Form()); hello(frm); // hello(ifrm); } It works when you exclude the recursive alias this: static if(!is(T == const)) alias constify this; Your original program crashes the compiler, which is always a bug. I filed an issue: https://issues.dlang.org/show_bug.cgi?id=14499
o!(const(T)) parameter.
I want a function with parameter o!(const(Form)) to accept both o!(Form) and o!(immutable(Form)) Is there a way to do it? import std.stdio; import std.traits; class Form { int number = 10; } struct o(T) { T data; this(T data) { this.data = data; } o!(const(Unqual!(T))) constify() const { return o!(const(Unqual!(T)))(data); } alias constify this; } void hello(o!(const(Form)) frm) { writeln(frm.data.number); writeln(typeof(frm.data).stringof); } void main() { writeln("This application works nicely"); auto frm = o!(Form) (new Form()); // auto ifrm = o!(immutable(Form)) (new immutable Form()); hello(frm); // hello(ifrm); }
Re: Delegate type deduction compile error
On Saturday, 25 April 2015 at 10:23:25 UTC, ref2401 wrote: struct MyStruct {} void main(string[] args) { string str = "blah-blah"; auto d1 = (MyStruct) { writeln("delegate-str: ", str); }; writeln(typeid(typeof(d1))); } dmd: 2067 os: Win8.1 build script: dmd main.d -ofconsole-app.exe -debug -unittest -wi - if delegate has no params or param is declared as int/char/float then the code compiles successfully. auto d1 = (int) { writeln("delegate-str: ", str); }; This seems to be a special case for builtin types. Builtin types cannot be used for identifiers, so "int" is recognized as the type here. - if I declare named param as string or MyStruct then the code compiles successfully too. auto d1 = (MyStruct ms) { writeln("delegate-str: ", str); }; Here you give both type and name, so it's clear which is which, to both you and the compiler. - if I declare anonymous parameter as string or MyStruct then the error compile occurs: auto d1 = (MyStruct) { writeln("delegate-str: ", str); }; main.d(21): Error: variable main.main.d1 type void is inferred from initializer (MyStruct) { writeln("delegate-str: ", str); } , and variables cannot be of type void main.d(21): Error: template lambda has no value Here "MyStruct" is interpreted as the _name_ of the parameter. Its type is inferred as void, because there's no context that says otherwise. Parameters cannot be typed void -> error. Generally, in function literals, a single identifier is interpreted as the name, because the type can often be inferred from context. And then it's nice not having to write the type out. Why does it happen?
BigInt to binary
Hi, Is there a way to apply a function "format" with BigInt? - import std.stdio, std.bigint, std.string; void main() { BigInt n = -10; string s = format("%b", n); // error writeln(s); }
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 05:07:04 UTC, Jens Bauer wrote: While I remember it ... I had to nullify a number of imports in stdint. They simply do not belong in there. :) Eg. I do not want FILE* if I aks for stdint. But FILE* is forced upon me, because wchar_t includes it. What does a wchar_t need a file-system for ? You better dismiss the idea of using druntime/phobos. They are not optimized for code size and contain a lot of stuff that'll never work. You can replace the core.stdc headers with bindings for nanolib, but again it's not necessary for doing useful stuff and should be done later.
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 07:31:45 UTC, Jens Bauer wrote: I wonder if you can get e.g. interfaces and classes working. I hope I will. ;) I think classes are really a must. The only thing that I (currently) see that could perhaps block this from working, would be missing support for static constructors and a missing memory allocator. Static constructors are possible if you strip down ModuleInfo (requires compiler hacking). You should care about that stuff last. It's way more important to make things work without dynamic memory allocation first. You can still malloc+emplace classes later. That means 'new' and 'delete' / 'malloc' and 'free' must be able to handle multiple RAM locations (because there's also external SRAM and external SDRAM). IIRC then the C/C++ malloc would simply can your sbrk implementation, so it only supports a single heap, which should be the external if available.
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 05:07:04 UTC, Jens Bauer wrote: I hope to find a good way to use import for microcontroller libraries, so it'll be easy for everyone. I'm thinking about something like ... import mcu.stm32f439.all I think that belongs in the makefile/dub.json as -version=STM32F439. Then you could simply import mcu.gpio or mcu.spi.
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 07:04:58 UTC, Jens Bauer wrote: Things that can be recycled would be carefully written drivers, such as LCD drivers that uses the SPI protocol. The SPI interface itself cannot be recycled, though, as each device has different SPI hardware and different GPIO hardware. You can very well abstract an SPI, just need to have an abstraction for pins. http://developer.mbed.org/handbook/SPI
Delegate type deduction compile error
struct MyStruct {} void main(string[] args) { string str = "blah-blah"; auto d1 = (MyStruct) { writeln("delegate-str: ", str); }; writeln(typeid(typeof(d1))); } dmd: 2067 os: Win8.1 build script: dmd main.d -ofconsole-app.exe -debug -unittest -wi - if delegate has no params or param is declared as int/char/float then the code compiles successfully. auto d1 = (int) { writeln("delegate-str: ", str); }; - if I declare named param as string or MyStruct then the code compiles successfully too. auto d1 = (MyStruct ms) { writeln("delegate-str: ", str); }; - if I declare anonymous parameter as string or MyStruct then the error compile occurs: auto d1 = (MyStruct) { writeln("delegate-str: ", str); }; main.d(21): Error: variable main.main.d1 type void is inferred from initializer (MyStruct) { writeln("delegate-str: ", str); } , and variables cannot be of type void main.d(21): Error: template lambda has no value Why does it happen?
std.json questions
Hello, D community! I'm pretty new to D and to compiled languages in general, and have primarily web background (PHP, JS), when JSON workflow is very organic. I was always sure that JSON is a simple thing, but std.json proves me wrong. So may I have a little advice from more experienced D folk? Say, I have a simple JSON file: { "entities" : [ { "x" : 0, "y" : 0, "texture" : "box1" }, { "x" : 100, "y" : 200, "texture" : "box2", "isControllable" : true } ] } First issue: what is the proper ("idiomatic") way to conver JSONValue to the proper types? Second: what is the proper way of handling boolean values in JSON (how to convert JSON_TYPE.TRUE and JSON_TYPE.FALSE to bool)? Righ now I'm doing is something like this: string data = readText("file.json"); JSONValue[string] parsedData = parseJSON(data).object; JSONValue[] etities = stateData["entities"].array; foreach(e; entities) { int x = to!int(e["x"].integer); int y = to!int(e["y"].integer); string texture = stripExtension(e["texture"].str); auto isControllable = "isControllable" in e; if (isControllable !is null) { if (e["isControllable"].type == JSON_TYPE.TRUE) { isControllable = true; } else { isControllable = false; } } } I think this is ugly and clunky approach, what is the beautiful one? A brief look at code.dlang.org gives us 7 (!) additional JSON libraries. Keeping in mind that D community isn't so huge, I think I'm not the only person struggling with std.json. Are there any plans on upgrading it? Thank you in advance!
Re: Degenerate Regex Case
On Friday, 24 April 2015 at 18:28:16 UTC, Guillaume wrote: Hello, I'm trying to make a regex comparison with D, based off of this article: https://swtch.com/~rsc/regexp/regexp1.html I've written my code like so: import std.stdio, std.regex; void main(string argv[]) { string m = argv[1]; auto p = ctRegex!("a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?aaa"); if (match(m, p)) { writeln("match"); } else { writeln("no match"); } } And the compiler goes into swap. Doing it at runtime is no better. I was under the impression that this particular regex was used for showcasing the Thompson NFA which D claims to be using. A quick investigation shows that it gets stuck at the end of pattern compilation stage. The problem is that as a last pass D's regex goes to optimize the pattern to construct simple bit-scanning engine as approximation for prefix of original pattern. And that process is a lot like Thompson NFA ... _BUT_ the trick of merging equivalent threads wasn't applied there. So in short: file a bug, optimizer absolutely should do de-duplication of threads. The golang code version of this runs fine, which makes me think that maybe D isn't using the correct regex engine for this particular regex. Or perhaps I'm using this wrong? It uses 2 kinds of engines, run-time one is Thompson NFA. Compile-time is (for now) still backtracking. --- Dmitry Olshansky
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 08:30:10 UTC, Rikki Cattermole wrote: On 25/04/2015 7:31 p.m., Jens Bauer wrote: Normally, one would want to import only the most necessary parts. Let's take an example: A microcontroller has USB, LCD controller, Ethernet, U(s)ART, SPI, CAN, I2S, I2C and also supports SDRAM. -But the program being developed only needs the LCD controller and the USART, so the Ethernet should not be imported, because if it's seen by the linker, the linker will include it in the final binary. This is because some drivers implement interrupt routines, which are weak+alias by default and *always* referenced by the exception vectors. Thus: In C: If you compile the C file containing the driver, the symbol will be found, and thus the code will be included in the final binary. If you have problems with too large a binaries, in D then it is a bug in the compiler. Never used code, should not hit the linker. Okay okay, it does happen. There is a trick with empty template bracket which allows for this. But it is a work around. It *should* happen (in this case). Consider void ETH_Handler() to be referenced by my exception vector (which is just an array of function pointers). If I do not import mcu.stm32f429.ethernet - then I will not get the driver. If, however, I do import mcu.stm32f429.ethernet, then the function 'void ETH_Handler()' will be bulit and the linker will see it in one of the .o files, and it will include it in the final binary. The developer can choose to use his own driver, because he's clever enough to write a better one than the one supplied by the vendor in this case. He then implements his own void ETH_Handler(). My current startup.d files do not support static constructors. static destructors are obsolete {...} main() never exits. You could definitely allocate the memory during linking. After all e.g. drivers will be singleton right? I think they will; I don't know if it will always be the case, but I currently can't think of a case where one would allocate a driver and then deallocate it, unless it's used only once for a short while. This would be a rare case, and in such cases, I believe the user could probably solve it. ;)
Re: Startup files for STM32F4xx
On 25/04/2015 7:31 p.m., Jens Bauer wrote: On Saturday, 25 April 2015 at 07:08:26 UTC, Rikki Cattermole wrote: I was referring to package.d files. And publically importing all below modules/packages. Normally, one would want to import only the most necessary parts. Let's take an example: A microcontroller has USB, LCD controller, Ethernet, U(s)ART, SPI, CAN, I2S, I2C and also supports SDRAM. -But the program being developed only needs the LCD controller and the USART, so the Ethernet should not be imported, because if it's seen by the linker, the linker will include it in the final binary. Thus the final binary will be huge, if all of those interfaces are imported. NXP made some #ifdef in their header files and it was terrible working with these. You couldn't build one library, which would work with all your projects, because then you would have a big lump containing everything, including all the stuff you wouldn't need. If you have problems with too large a binaries, in D then it is a bug in the compiler. Never used code, should not hit the linker. Okay okay, it does happen. There is a trick with empty template bracket which allows for this. But it is a work around. I wonder if you can get e.g. interfaces and classes working. I hope I will. ;) I think classes are really a must. The only thing that I (currently) see that could perhaps block this from working, would be missing support for static constructors and a missing memory allocator. The missing memory allocator would be entirely because I would have disabled it; this might be necessary on very small devices (such as 1K RAM devices or worse). Devices that have 64K on-chip memory might be big enough for using new and delete on a regular basis (this is just guesswork). If the programmer is instantiating classes carefully, it should be possible to avoid too many problems. My current startup.d files do not support static constructors. static destructors are obsolete, because a microcontroller never 'exits'. If it's turned off, the constructed data gets deallocated automatically when the power drops too low anyway. ;) In other words: Normally main() never exits. You could definitely allocate the memory during linking. After all e.g. drivers will be singleton right?
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 07:08:26 UTC, Rikki Cattermole wrote: I was referring to package.d files. And publically importing all below modules/packages. Normally, one would want to import only the most necessary parts. Let's take an example: A microcontroller has USB, LCD controller, Ethernet, U(s)ART, SPI, CAN, I2S, I2C and also supports SDRAM. -But the program being developed only needs the LCD controller and the USART, so the Ethernet should not be imported, because if it's seen by the linker, the linker will include it in the final binary. Thus the final binary will be huge, if all of those interfaces are imported. NXP made some #ifdef in their header files and it was terrible working with these. You couldn't build one library, which would work with all your projects, because then you would have a big lump containing everything, including all the stuff you wouldn't need. I wonder if you can get e.g. interfaces and classes working. I hope I will. ;) I think classes are really a must. The only thing that I (currently) see that could perhaps block this from working, would be missing support for static constructors and a missing memory allocator. The missing memory allocator would be entirely because I would have disabled it; this might be necessary on very small devices (such as 1K RAM devices or worse). Devices that have 64K on-chip memory might be big enough for using new and delete on a regular basis (this is just guesswork). If the programmer is instantiating classes carefully, it should be possible to avoid too many problems. My current startup.d files do not support static constructors. static destructors are obsolete, because a microcontroller never 'exits'. If it's turned off, the constructed data gets deallocated automatically when the power drops too low anyway. ;) In other words: Normally main() never exits. At worse maybe structs + alias this + meta programming for e.g. drivers? When you mention drivers, I'm reminded that on some devices, such as the STM32F4xx, we have two types of on-chip SRAM: CCMRAM and normal local SRAM. The CCMRAM is not accessible by the DMA for instance. That means if objects are allocated here, they cannot be accessed by the DMA. In some cases, it would be desirable to 'prefer' allocating in CCMRAM and if absolutely necessary, allocate in the other local SRAM. That means 'new' and 'delete' / 'malloc' and 'free' must be able to handle multiple RAM locations (because there's also external SRAM and external SDRAM).
Re: Weird OSX issue
Jacob Carlborg writes: > On 2015-04-24 20:37, Steven Schveighoffer wrote: > >> So am I going crazy? Or is dmd doing things differently depending on >> where its environment is? Any compiler gurus out there understand why >> the symbol is different? >> >> I don't want to file a bug with this, because it seems dependent on >> installation location, would possibly not be reproducible. > > I can't reproduce this with DMD from DVM (compiler is installed in the > user home directory). I have lots of version laying around and they all worked fine on the posted code. But maybe a clue here... $ ~/dmd2.066.0/osx/bin/dmd mod1.d $ nm mod1.o | grep start U _D4core6thread6Thread5startMFZv $ dmd mod1.d $ nm mod1.o | grep start U _D4core6thread6Thread5startMFNbZC4core6thread6Thread --- a/src/core/thread.d +++ b/src/core/thread.d @@ -587,7 +587,7 @@ class Thread * Throws: * ThreadException if the thread fails to start. */ -final Thread start() +final Thread start() nothrow in { assert( !next && !prev ); I wonder if dmd -v will show where its picking up stuff.
Re: Startup files for STM32F4xx
On 25/04/2015 7:04 p.m., Jens Bauer wrote: On Saturday, 25 April 2015 at 05:14:57 UTC, Rikki Cattermole wrote: On 25/04/2015 5:07 p.m., Jens Bauer wrote: I hope to find a good way to use import for microcontroller libraries, so it'll be easy for everyone. I'm thinking about something like ... import mcu.stm32f439.all Ugh, package.d? I don't know ... Maybe, but what I have in mind is a tree like this: mcu/ common/ ... (Cypress Semiconductor here) ... lpc81x/ lpc82x/ lpc15xx/ lpc175x_6x/ lpc177x_8x/ lpc40xx/ lpc43xx/ ... (Freescale Kinetis here) ... stm32f401/ stm32f405/ stm32f407/ stm32f411/ stm32f415/ stm32f417/ stm32f427/ stm32f429/ stm32f437/ stm32f439/ ... (Texas Instruments here) ... -Because there would be some things that can be recycled for all microcontrollers, and there will be a lot of different device types. Things that can be recycled would be carefully written drivers, such as LCD drivers that uses the SPI protocol. The SPI interface itself cannot be recycled, though, as each device has different SPI hardware and different GPIO hardware. It could also be 'minimalistic memory handlers' and other algorithms, which do not know anything about hardware. It might be possible to make a CMSIS which can be recycled as well. I was referring to package.d files. And publically importing all below modules/packages. I wonder if you can get e.g. interfaces and classes working. At worse maybe structs + alias this + meta programming for e.g. drivers?
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 05:14:57 UTC, Rikki Cattermole wrote: On 25/04/2015 5:07 p.m., Jens Bauer wrote: I hope to find a good way to use import for microcontroller libraries, so it'll be easy for everyone. I'm thinking about something like ... import mcu.stm32f439.all Ugh, package.d? I don't know ... Maybe, but what I have in mind is a tree like this: mcu/ common/ ... (Cypress Semiconductor here) ... lpc81x/ lpc82x/ lpc15xx/ lpc175x_6x/ lpc177x_8x/ lpc40xx/ lpc43xx/ ... (Freescale Kinetis here) ... stm32f401/ stm32f405/ stm32f407/ stm32f411/ stm32f415/ stm32f417/ stm32f427/ stm32f429/ stm32f437/ stm32f439/ ... (Texas Instruments here) ... -Because there would be some things that can be recycled for all microcontrollers, and there will be a lot of different device types. Things that can be recycled would be carefully written drivers, such as LCD drivers that uses the SPI protocol. The SPI interface itself cannot be recycled, though, as each device has different SPI hardware and different GPIO hardware. It could also be 'minimalistic memory handlers' and other algorithms, which do not know anything about hardware. It might be possible to make a CMSIS which can be recycled as well.