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: 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.
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.
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.
@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
Am Sat, 25 Apr 2015 11:38:45 +
schrieb Martin Nowak c...@dawg.eu:
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: 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 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
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: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 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
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 17:11:22 UTC, Johannes Pfau wrote:
Am Sat, 25 Apr 2015 11:38:45 +
schrieb Martin Nowak c...@dawg.eu:
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!).
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: 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%3ADtype=Repositoriesref=searchresults some of them might have an API to save load an object or a struct in a single call.
Re: Startup files for STM32F4xx
Am Sat, 25 Apr 2015 18:31:45 +
schrieb Jens Bauer doc...@who.no:
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: 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 doc...@who.no:
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: 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: 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: 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: 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: 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 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: 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 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 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: 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
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: 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!!
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: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 06:25:08 UTC, tom wrote: On Saturday, 25 April 2015 at 04:01:47 UTC, Jens Bauer wrote: (still no automatic mirroring, though I've installed https://github.com/miracle2k/gitolite-simple-mirror) it should be fairly simple, check the logs. It's probably something silly being wrong. The logs does not report any errors, except for that stupid line I always get from gitweb: CGI::param called in list context from package main line 874 (they promised that it was fixed in v2.1, but I'm on 2.3.6 and it still spams my Apache error-log). The gitolite-log also seems to be fine. most probably something failing with authentication. I tried a manual clone from the 'd' server's account, it seems to clone without problems (and there's no passphrase blocking it from completing) another approach would be that you just add the github as a second remote repository and push to both (e.g. via a simple shell alias in your shells rc file) So far, I made a small script that mirrors when I run it. I could also add a cron-job on the server until I find a solution; but I think I'll stick to the manual mirror until I find out what the problem is. i'm mostly on os x / archlinux. both contain packages for openocd. i just did a ```brew install openocd --HEAD``` and it installed smoothly. That's great. Did you build GDC or LDC for arm-none-eabi already ? If you have built the compiler too, then I think you're all set. The linker-scripts should work fine and the startup file is ready for use. What's still missing is some kind of portable Makefile. My own Makefile seem to be too complex to port. It might be best to start from scratch with a simple Makefile.
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.
Re: Startup files for STM32F4xx
On Saturday, 25 April 2015 at 04:01:47 UTC, Jens Bauer wrote: (still no automatic mirroring, though I've installed https://github.com/miracle2k/gitolite-simple-mirror) it should be fairly simple, check the logs. most probably something failing with authentication. (btw, for those who don't know it: https://github.com/gogits/gogs more or less a simplified github clone that runs as a single binary, pretty neat) another approach would be that you just add the github as a second remote repository and push to both (e.g. via a simple shell alias in your shells rc file) i'm mostly on os x / archlinux. both contain packages for openocd. i just did a ```brew install openocd --HEAD``` and it installed smoothly.
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: Weird OSX issue
Jacob Carlborg d...@me.com 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: 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
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!
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?
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: 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 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 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
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?
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: 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 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.
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: 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
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: 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: std.json questions
tired_eyes pastuho...@gmail.com 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
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.
