Hyperterminal serial port
Hi, I am wanting to establish a virtual serial port connection between an 89c51 being emulated in Proteus and Hyper Terminal running in Windows. How do I go about doing this? Thanks in advance
Re: Why after writeln the binaryHeap become empty?
On Wednesday, 19 June 2019 at 06:00:28 UTC, Jonathan M Davis wrote: On Tuesday, June 18, 2019 10:27:46 PM MDT lili via Do you known reason for why Dlang Range are consumed by iterating over them. I this design is strange. If you want an overview of ranges, you can watch this: https://www.youtube.com/watch?v=A8Btr8TPJ8c You can also read this: http://ddili.org/ders/d.en/ranges.html - Jonathan M Davis And this excerpt from Learning D: https://hub.packtpub.com/understanding-ranges/
Re: Why after writeln the binaryHeap become empty?
On Tuesday, June 18, 2019 10:27:46 PM MDT lili via Digitalmars-d-learn wrote: > On Tuesday, 18 June 2019 at 17:25:51 UTC, Johannes Loher wrote: > > The result of heapify is a BinaryHeap, which is a range. writeln > > basically prints ranges by iterating over them and printing > > each element > > (except for the types which are special cased, such as dynamic > > arrays > > etc.). However, ranges are consumed by iterating over them, > > which > > explains the behavior because writeln is not special cased for > > BinaryHeaps. > > > > Funnily enough, BinaryHeap does not implement a "save" method, > > which is the usual way of making ranges copiable, i.e. making > > them ForwardRanges. In this case I believe save could even > > simply be an alias to dup. > > Do you known reason for why Dlang Range are consumed by iterating > over them. I this design is strange. If you want an overview of ranges, you can watch this: https://www.youtube.com/watch?v=A8Btr8TPJ8c You can also read this: http://ddili.org/ders/d.en/ranges.html - Jonathan M Davis
Re: Where can find fix length array memory layout document
On Tuesday, 18 June 2019 at 17:29:49 UTC, Cym13 wrote: On Tuesday, 18 June 2019 at 17:25:42 UTC, Cym13 wrote: On Tuesday, 18 June 2019 at 13:05:03 UTC, lili wrote: On Tuesday, 18 June 2019 at 12:39:45 UTC, Dennis wrote: [...] Thanks a lot, where is a core.stdcpp.array , How to user it? I test but get a error ``` auto aa = array!(int, 4); //error ``` Please don't shorten your code or errors to the point where there's hardly any information left: it's hard to help you if we can't know what you did and what went wrong. Forgot to say that it's probably because you don't actually build an array here, try adding parentheses: ``` auto aa = array!(int, 4)(); ``` array!(int,4)(); compile occurs a error say: no overload matches for array
Re: Why after writeln the binaryHeap become empty?
On Tuesday, 18 June 2019 at 17:25:51 UTC, Johannes Loher wrote: The result of heapify is a BinaryHeap, which is a range. writeln basically prints ranges by iterating over them and printing each element (except for the types which are special cased, such as dynamic arrays etc.). However, ranges are consumed by iterating over them, which explains the behavior because writeln is not special cased for BinaryHeaps. Funnily enough, BinaryHeap does not implement a "save" method, which is the usual way of making ranges copiable, i.e. making them ForwardRanges. In this case I believe save could even simply be an alias to dup. Do you known reason for why Dlang Range are consumed by iterating over them. I this design is strange.
Re: What's the difference between DIP25 and DIP1000?
On Tuesday, 18 June 2019 at 21:57:32 UTC, Jonathan M Davis wrote: -snip- Thank you, it's clear to me now :)
Re: What's the difference between DIP25 and DIP1000?
On Tuesday, June 18, 2019 8:53:31 AM MDT Emmanuelle via Digitalmars-d-learn wrote: > Hi, I've been reading about DIP25 and DIP1000 and I'm not quite > sure if I understand the difference between the two—is DIP1000 > supposed to be a rework of DIP25? And what's the difference > between `return ref` and `return scope`? Also, will there be any > compiler version where `-preview=dip25` and/or `-preview=dip1000` > are the default? > > Thanks! DIP 25 only has to do with making returning ref safe. The basic problem is something like ref int foo() { int i; return bar(i); } ref int bar(ref int i) { return i; } When foo returns, it ends up returning a ref to a local variable that then doesn't exist. That's caught with simpler code such as ref int foo() { int i; return i; } but by passing it to a function like bar, the compiler can no longer see that what's being returned is a ref of a local variable. And what bar is doing would be perfectly legitimate if it were given something other than a local variable or if foo didn't return bar's result. So, DIP 25 was introduced to fix the problem. Basically, what DIP 25 does is require that any function that accepts a ref and returns that same ref needs to have the ref parameter marked with return. That way, when the compiler is compiling a function like foo, it can see whether bar is returning a ref to the ref parameter or not and thus whether it's safe to return the result of bar from foo. DIP 25 only deals with this one issue and has no effect on the type system. It just allows the compiler to detect whether a function returns a ref parameter. DIP 1000, on the other hand, actually affects the type system. When scope is put on a variable, it's actually part of its type, and scope variables are not allowed to have any references to them escape, meaning that once something is scope, it can pretty much only be passed to something else that takes it as scope. That can apply to ref parameters, but it can also apply to pointers, class references, dynamic arrays, etc. So, it's much more general than what DIP 25 is trying to do. Something like ref int* foo() { auto ptr = new int(42); return bar(ptr); } ref int* bar(return ref int* ptr) { return ptr; } int* baz = foo(); would be perfectly legal with DIP 25, whereas with DIP 1000, something like scope ref int* foo() { auto ptr = new int(42); return bar(ptr); } scope ref int* bar(return scope ref int* ptr) { return ptr; } int* baz = foo(); wouldn't be. Unfortunately, actually understanding all of the ins and outs of DIP 1000 is pretty complicated, and I haven't spent enough time with it, so I probably can't explain it well enough. But it covers a _lot_ more than DIP 25, and IIRC, DIP 1000 depends on DIP 25. As for when either of them will become the default? I have no clue. -dip25 has been around for years and AFAIK gets used very little, whereas -dip1000 is quite new. Historically, we've done a poor job of switching to new behavior like this when it breaks existing code, and the change usually simply doesn't happen. IIRC, Walter intends to try to make it so that code compiled with -dip1000 and code compiled without it are compatible (so that people can actually start using -dip1000 and still have their code interact with code that doesn't use it) and work towards making -dip1000 the default behavior, but I wouldn't expect such a change to happen soon. However, Walter is behind this strongly enough that I expect that it will _eventually_ become the default behavior. - Jonathan M Davis
Re: Component based programming in D
On Tue, Jun 18, 2019 at 09:22:28PM +, Aurélien Plazzotta via Digitalmars-d-learn wrote: > On Tuesday, 18 June 2019 at 09:17:09 UTC, Bart wrote: > > > Can someone help me understand this a little better and how I'd go > > about using it in D? Specifically I'm looking at the pros and cons, > > what are the real similarities and differences to oop, and how one > > implements them in D(taking in to account D's capabilities). [...] > Perhaps, you should be interested by this article written by our > famous Walter: > http://www.drdobbs.com/architecture-and-design/component-programming-in-d/240008321 > > You'll get a whole new idea about reusability :) And also: https://wiki.dlang.org/Component_programming_with_ranges T -- English has the lovely word "defenestrate", meaning "to execute by throwing someone out a window", or more recently "to remove Windows from a computer and replace it with something useful". :-) -- John Cowan
Re: Component based programming in D
On Tuesday, 18 June 2019 at 09:17:09 UTC, Bart wrote: Can someone help me understand this a little better and how I'd go about using it in D? Specifically I'm looking at the pros and cons, what are the real similarities and differences to oop, and how one implements them in D(taking in to account D's capabilities). Thanks. Perhaps, you should be interested by this article written by our famous Walter: http://www.drdobbs.com/architecture-and-design/component-programming-in-d/240008321 You'll get a whole new idea about reusability :)
Re: Component based programming in D
On Tuesday, 18 June 2019 at 09:17:09 UTC, Bart wrote: I'm new to component based programming. I've read it is an alternative to oop for speed. I don't understand how it is possible to have an alternative to oop and still have oop like behavior(polymorphism) nor how to do this. It seems all the great things oop offers(all the design patterns) would be impossible. The benefits are suppose to better reusability as components are more isolated in their dependencies. Can someone help me understand this a little better and how I'd go about using it in D? Specifically I'm looking at the pros and cons, what are the real similarities and differences to oop, and how one implements them in D(taking in to account D's capabilities). Thanks. I don't know a lot about component-based programming per se. (I might use it all the time, I just don't know the term.) OOP as implemented by Java, C# etc. use virtual functions and inheritance to compose behaviour, also known as polymorphism. This has a slight overhead at runtime. In like >90% of the cases however, you can deduce statically what override/implementation of a function will be called. In D, we have the means to make that deduction at compile time. The most simple means is duck typing: int fun(T)(T instance) { return instance.number(); } We have a templated function, that is: a function that takes an instance of any type. Think of generics, but more liberal. If we call the function with an object: class Dice { final int number() { return 6; } } fun(new Dice()); the compiler generates a template instance, that is, a `fun` that takes a `Dice` instance as its argument. It will then compile as if you have written the Dice type there yourself: int fun(Dice instance) { return instance.number(); } This compiles because the class Dice defines a method called `number`. However, we can put any type in there that defines a number() method. In classic OOP, one would use an interface for this interface Number { int number(); } class Dice : Number { int number() { return 6; } } Using duck typing, the compiler just checks whether the code compiles given the type. If we have other types that implement number, like a Roulette class, we can simply pass an instance of that class to the function and the compiler figures it out. We don't need to define an interface. For large methods, it can be quite unclear what methods a type need to define in order to be passed in. int fun(T)(T instance) // Only if T has number() method { // Large amount of code here return instance.number(); } In this example we can only pass in a T if it defines a `number()` method. We annotated it in a comment. However, D can also explicitly check it using traits (https://dlang.org/phobos/std_traits.html) or the nuclear option: __traits(compiles, ...), which checks if a certain expression compiles successfully. Doing it the quick and dirty way, we can explicitly define our desired instance interface: int fun(T)(T instance) if(__traits(compiles, {int x = instance.number()} )) { // Large amount of code here return instance.number(); } We add a constraint to our template: our function is valid for any T for which the number() method returns an integer. This is just the surface, you can read https://github.com/PhilippeSigaud/D-templates-tutorial for a technical introduction. One thing I really like about this is that we preserve the actual type during the whole function. This means that we can call other functions using a strongly-typed argument or do other things based on what type we get. In my personal project, I need to rewrite a bunch of functions that took one type (Card), but now need to take another, reduced type (SimpleCard) as well. The functions currently output cards grouped in sets. Card has some properties (e.g. isFolded, isShown), and SimpleCard is just the value representation (e.g. spades-4). I can use classic inheritance Card extends SimpleCard, but that means I lose my type info along the way. Using duck typing, my functions work for any Card-like object and preserve the type as well. If I need polymorphism, I can achieve that using normal overload rules, e.g. void fun(CardLike)(CardLike card) { foo(card); } void foo(Card card) {} void foo(SimpleCard card) {} void foo(FakedCard card) {} The classes can be kept small - new behaviour can be glued to classes without having impact on existing code. (I once though about why my pet project was progressing so much faster than regular projects. I figured because I rarely changed code - I just added code in different files and changed one line to activate it.)
Re: Component based programming in D
I guess design patterns are independent of implementation language. Anyway, I suspect OO is incidental in components. D probably can do it better than C++ at least. Do search for the video of a talk Walter Bright gave on component programming in D.
Re: Is there a way to load a `RIP` register relative address in inline asm?
On Tuesday, 18 June 2019 at 17:10:50 UTC, Adam D. Ruppe wrote: On Tuesday, 18 June 2019 at 17:09:48 UTC, Adam D. Ruppe wrote: pop EAX; errr you can see my 32 bit bias here (forgive me, I'm old), but you know what i mean :) Thank you, quite clever. There is also the "$" symbol that is related: https://dlang.org/spec/iasm.html#special_symbols
Re: Why after writeln the binaryHeap become empty?
On Tuesday, June 18, 2019 9:45:33 AM MDT lili via Digitalmars-d-learn wrote: > Hi Guys: > see this code > ~~~ > int[] ar = [1,2,3,4,52,34,22]; > auto h = heapify(ar); > assert(h.length() == ar.length); > writeln("h:",h); > assert(h.empty()); > ~~~ > dmd v2.086.0 run all assert passed. Why? Looking at std/container/binaryheap.d, heapify returns the type BinaryHeap which provides the API for an input range but no toString. As such, writeln likely uses the range API to read the elements and print them. And that's going to pop all of the elements off in the process. In general, if you pass a range to something and you don't want it to be consumed, then you need to call save on it so that you pass a copy (for many ranges, copying them is equivalent to calling save on them, but that's not part of the range API, and it's not true for all ranges). However, from the looks of it, the BinaryHeap is a just a basic input range, not a forward range, so it doesn't have save. That means that reading it will always consume it. Looking over BinaryHeap, I don't think that it's actually possible to iterate through its elements without removing them from the BinaryHeap. As such, you can't print them without removing them from the BinaryHeap. - Jonathan M Davis
Re: Where can find fix length array memory layout document
On Tuesday, 18 June 2019 at 17:25:42 UTC, Cym13 wrote: On Tuesday, 18 June 2019 at 13:05:03 UTC, lili wrote: On Tuesday, 18 June 2019 at 12:39:45 UTC, Dennis wrote: [...] Thanks a lot, where is a core.stdcpp.array , How to user it? I test but get a error ``` auto aa = array!(int, 4); //error ``` Please don't shorten your code or errors to the point where there's hardly any information left: it's hard to help you if we can't know what you did and what went wrong. Forgot to say that it's probably because you don't actually build an array here, try adding parentheses: ``` auto aa = array!(int, 4)(); ```
Re: Why after writeln the binaryHeap become empty?
Am 18.06.19 um 17:45 schrieb lili: > Hi Guys: > see this code > ~~~ > int[] ar = [1,2,3,4,52,34,22]; > auto h = heapify(ar); > assert(h.length() == ar.length); > writeln("h:",h); > assert(h.empty()); > ~~~ > dmd v2.086.0 run all assert passed. Why? The result of heapify is a BinaryHeap, which is a range. writeln basically prints ranges by iterating over them and printing each element (except for the types which are special cased, such as dynamic arrays etc.). However, ranges are consumed by iterating over them, which explains the behavior because writeln is not special cased for BinaryHeaps. In order to avoid this, you can make a copy of the BinaryHeap before printing it: ``` import std; void main() { int[] ar = [1, 2, 3, 4, 52, 34, 22]; auto h = heapify(ar); assert(h.length() == ar.length); writeln("h:", h.dup); assert(!h.empty()); } ``` Funnily enough, BinaryHeap does not implement a "save" method, which is the usual way of making ranges copiable, i.e. making them ForwardRanges. In this case I believe save could even simply be an alias to dup.
Re: Where can find fix length array memory layout document
On Tuesday, 18 June 2019 at 13:05:03 UTC, lili wrote: On Tuesday, 18 June 2019 at 12:39:45 UTC, Dennis wrote: On Tuesday, 18 June 2019 at 12:26:14 UTC, lili wrote: [...] I'm assuming you mean writeln([1].sizeof). An array literal is a slice of a dynamic array (which is length + pointer, so 2*size_t size). A fixed size array has to be declared as a local / member variable, and then the content is on the stack: ``` int[10] a; writeln(a.sizeof); // 40 writeln(a[].sizeof); // 16 on 64-bit or 8 on 32-bit ``` To get a static array literal, you can use the library function staticArray: ``` import std.array; writeln([1, 2, 3].staticArray.sizeof); // 12 ``` Thanks a lot, where is a core.stdcpp.array , How to user it? I test but get a error ``` auto aa = array!(int, 4); //error ``` Please don't shorten your code or errors to the point where there's hardly any information left: it's hard to help you if we can't know what you did and what went wrong.
Re: Is there a way to load a `RIP` register relative address in inline asm?
On Tuesday, 18 June 2019 at 17:09:48 UTC, Adam D. Ruppe wrote: pop EAX; errr you can see my 32 bit bias here (forgive me, I'm old), but you know what i mean :)
Re: Is there a way to load a `RIP` register relative address in inline asm?
On Tuesday, 18 June 2019 at 16:56:18 UTC, Stefanos Baziotis wrote: I can't do for example: lea RAX, [RIP+something]; Generally, RIP does not seem to be available. The general trick in x86 assembly for this is call next; next: pop EAX; The call instruction pushes RIP to the stack (for a future ret instruction) but if you put it right where you are, you can simply pop it right back off the stack into another register.
Is there a way to load a `RIP` register relative address in inline asm?
I can't do for example: lea RAX, [RIP+something]; Generally, RIP does not seem to be available.
Why after writeln the binaryHeap become empty?
Hi Guys: see this code ~~~ int[] ar = [1,2,3,4,52,34,22]; auto h = heapify(ar); assert(h.length() == ar.length); writeln("h:",h); assert(h.empty()); ~~~ dmd v2.086.0 run all assert passed. Why?
What's the difference between DIP25 and DIP1000?
Hi, I've been reading about DIP25 and DIP1000 and I'm not quite sure if I understand the difference between the two—is DIP1000 supposed to be a rework of DIP25? And what's the difference between `return ref` and `return scope`? Also, will there be any compiler version where `-preview=dip25` and/or `-preview=dip1000` are the default? Thanks!
Blog Post #0045 - Split a Window into Panes
Two announcements today... First, today's post covers splitting a window into panes. You can find it here: https://gtkdcoding.com/2019/06/18/0045-split-a-window-into-panes.html Second, you'll notice some changes in the site. At the prompting of a bunch of people here and elsewhere, I've starting making the site more visual. - The first step was to color-code the blog entries by topic. - You'll also notice that the first three posts from back in January now have screenshots. And just a quick tip of the hat to Michelle Long, Greatsam4sure, and sanyayss for suggesting it. It just took me a while to get organized enough to do it. Future Facelist Plans - get screenshots and any other appropriate graphics into each blog post. If there are any posts you think need something special, image wise, please let me know at: gtkdcoding over on gmail. (please suffix a dot and a com and shove an 'at' in the middle there) - icons for each topic will eventually appear alongside each link on the main page so as to make the topics even easier to pick out. And if anyone has any other suggestions, please let me know those too. Due to time constraints, I won't promise to implement all of them, but I'll do my best. Also, if anyone knows how to implement a non-paid commenting system on GitHub Pages, I'd appreciate some advice on how to go about it. I always have a hard time with systems involving three or more languages (like in this case: Jekyll, Liquid, HTML, markdown, CSS and Ruby.
Re: Where can find fix length array memory layout document
On Tuesday, 18 June 2019 at 12:39:45 UTC, Dennis wrote: On Tuesday, 18 June 2019 at 12:26:14 UTC, lili wrote: Hi guys: Is the Dlang fix-length array alloc on stack? when a test writeln([1]).sizeof //16 writeln([2]).sizeof //16 Why, What is the fix-length array memory layout. I'm assuming you mean writeln([1].sizeof). An array literal is a slice of a dynamic array (which is length + pointer, so 2*size_t size). A fixed size array has to be declared as a local / member variable, and then the content is on the stack: ``` int[10] a; writeln(a.sizeof); // 40 writeln(a[].sizeof); // 16 on 64-bit or 8 on 32-bit ``` To get a static array literal, you can use the library function staticArray: ``` import std.array; writeln([1, 2, 3].staticArray.sizeof); // 12 ``` Thanks a lot, where is a core.stdcpp.array , How to user it? I test but get a error ``` auto aa = array!(int, 4); //error ```
Re: Where can find fix length array memory layout document
On Tue, Jun 18, 2019 at 2:30 PM lili via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote: > Hi guys: > Is the Dlang fix-length array alloc on stack? when a test > writeln([1]).sizeof //16 > writeln([2]).sizeof //16 > Why, What is the fix-length array memory layout. > When you do [1] without staticArray it will be automaticaly change to array slice which consist of pointer to data (8bytes on 64bit) and length of array again 8byte on 64bit
Re: Where can find fix length array memory layout document
On Tuesday, 18 June 2019 at 12:26:14 UTC, lili wrote: Hi guys: Is the Dlang fix-length array alloc on stack? when a test writeln([1]).sizeof //16 writeln([2]).sizeof //16 Why, What is the fix-length array memory layout. I'm assuming you mean writeln([1].sizeof). An array literal is a slice of a dynamic array (which is length + pointer, so 2*size_t size). A fixed size array has to be declared as a local / member variable, and then the content is on the stack: ``` int[10] a; writeln(a.sizeof); // 40 writeln(a[].sizeof); // 16 on 64-bit or 8 on 32-bit ``` To get a static array literal, you can use the library function staticArray: ``` import std.array; writeln([1, 2, 3].staticArray.sizeof); // 12 ```
Re: Where can find fix length array memory layout document
import std.stdio; import std.array : staticArray; void main() { writeln([1].staticArray.sizeof); //4 writeln([2,5].staticArray.sizeof); //8 } On Tue, Jun 18, 2019 at 2:30 PM lili via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote: > Hi guys: > Is the Dlang fix-length array alloc on stack? when a test > writeln([1]).sizeof //16 > writeln([2]).sizeof //16 > Why, What is the fix-length array memory layout. >
Where can find fix length array memory layout document
Hi guys: Is the Dlang fix-length array alloc on stack? when a test writeln([1]).sizeof //16 writeln([2]).sizeof //16 Why, What is the fix-length array memory layout.
Re: Range violation error when reading from a file
On Tuesday, 18 June 2019 at 01:15:54 UTC, Samir wrote: On Monday, 17 June 2019 at 03:46:11 UTC, Norm wrote: On Monday, 17 June 2019 at 00:22:23 UTC, Samir wrote: Any suggestions on how to rectify? You could change the IF to `if(line.length > 0 && line[0] == '>')` Thanks, Norm. That seemed to do the trick and fixed the error. On Monday, 17 June 2019 at 11:25:01 UTC, aliak wrote: On Monday, 17 June 2019 at 00:22:23 UTC, Samir wrote: HOWEVER, the output is interesting. There IS a blank line between the last line and the prompt: That's because you're using write*ln*. So even though line is empty, you still output a new line. Curious. I am going to have to think about that for a bit as I don't quite understand. I mean this: $ dmd -run readfile.d 1) file.eof() == false line = "> line 1" writeln("lines 1" + \n); 2) file.eof() == false line = line 2 writeln("line 2" + \n); 3) file.eof() == false line = line 3 writeln("line 3" + \n); 4) file.eof() == false line = > line 4 writeln("> line 4" + \n); 5) file.eof() == false line = line 5 writeln("line 5" + \n); 6) file.eof() == false line = "" // empty since there're no lines left in file writeln("" + \n); <-- this is your blank line 7) file.eof() == true
Component based programming in D
I'm new to component based programming. I've read it is an alternative to oop for speed. I don't understand how it is possible to have an alternative to oop and still have oop like behavior(polymorphism) nor how to do this. It seems all the great things oop offers(all the design patterns) would be impossible. The benefits are suppose to better reusability as components are more isolated in their dependencies. Can someone help me understand this a little better and how I'd go about using it in D? Specifically I'm looking at the pros and cons, what are the real similarities and differences to oop, and how one implements them in D(taking in to account D's capabilities). Thanks.
Re: How does this template work?
On Sunday, 16 June 2019 at 15:11:29 UTC, Robert M. Münch wrote: How does the observerObject Template and function work? I'm struggling because both use the same name and how is the template parameter R deduced/where is it coming from? Looks like it's somehow implicitly deduced. Eponymous templates: https://dlang.org/spec/template.html#implicit_template_properties "Templated types" are actually particular cases of eponymous templates: https://dlang.org/spec/template.html#StructTemplateDeclaration class ObserverObject(R, E...) {...} is equivalent to tempalte ObserverObject(R, E...) { class ObserverObject(R, E...) {...} } So this is I think how everything is made to work with the same compiler engine, both individual "templated types" and "eponymous templates". It's considered idiomatic, but if you don't like it in your case, it's very easy for the author to avoid it: just make the names different in any way. template Observer(E) { ObserverObject!(R, E) Object(R)(R range) { return new ObserverObject!(R, E)(range); } } auto observer = Observer!int.Object(TestObserver());