Re: Obsecure problem 1
On Saturday, 30 July 2022 at 23:40:44 UTC, pascal111 wrote: Provide me a free solution better than code::blocks with available gdc compiler I found. SDB@79 I don't know if's "better" but there is Visual Studio Code and IntelliJ IDEA for example. Yeah ctrl+v doesn't work on XTERM, the middle mouse button should. I found this in the wild: is super weird but in xterm you can copy just by selecting the text, the text is going to get copied to xwindows clipboard not to gnome one so ctrl+v or menus are not going to work for pasting you need to use the middle button of the mouse and in some windows shift+insert uses to work too. so: select the text in the terminal keep it open go to any text editor or the browser and press the middle button to paste if you are on a mac you can simulate the middle button pressing the touchpad with 3 fingers and if you have a 2 buttons mouse you can simulate the middle one pressing both at the same time. A probably more sane option would be to configure codeblocks to use gnome-terminal instead of xterm, in settings -> environment -> general settings you can change it but it seems to close as soon as you try to launch the app If that doesn't work you have to try another keyboard layout or such configuration or bind the function to another key if your middle mouse button is not present or is not recognized properly.
Re: Does anyone here know how to create a Telegram bot in D?
On Saturday, 30 July 2022 at 05:12:23 UTC, AnimusPEXUS wrote: so basically you have to do http-client programming also there's some outdated tg packages in repo https://code.dlang.org/search?q=telegram Thanks you very much.
Re: Obsecure problem 1
Another version of the program: https://github.com/pascal111-fra/D/blob/main/proj04.d
Re: Obsecure problem 1
On Saturday, 30 July 2022 at 22:45:14 UTC, Salih Dincer wrote: On Saturday, 30 July 2022 at 22:17:10 UTC, pascal111 wrote: The program works fine now: https://i.postimg.cc/3wkgXmVs/Screenshot-from-2022-07-31-00-04-23.png I have a suggestion for you. Use modern possibilities instead of applying functions used in the past to the present. For example, in a world with UTF, ordinary string reversing can result in erroneous results. I'm trying, really, to understand modern D features, but I'm from old school, C pure programming and BASIC language, and such languages and styles. D as it's obvious to all of us is a multi-paradigm language and has so advanced features, even its references, I can't understand 'em well, it's 100% new modern language, but every time I'll learn a new feature of it for that I can't surround all of its techniques at once. Also, please don't use pictures, use Markdown instead... Provide me a free solution better than code::blocks with available gdc compiler I found. SDB@79
Re: Obsecure problem 1
On Saturday, 30 July 2022 at 22:28:52 UTC, frame wrote: On Saturday, 30 July 2022 at 22:13:55 UTC, pascal111 wrote: Because copying the running window contents is not allowed, I couldn't do it in Code::Blocks. Not allowed? o.O Did you try to select the text and insert it via middle mouse button in another window? Those terminals usually copy the text by selection automatically. I tried what you said, and also ctrl+c doesn't work, nothing works, I can't copy the contents of this terminal.Now you have two choices, 1) I continue using pictures 2) I stop that and be unable to describe what's happening in the running time.
Re: Obsecure problem 1
On Saturday, 30 July 2022 at 22:17:10 UTC, pascal111 wrote: The program works fine now: https://i.postimg.cc/3wkgXmVs/Screenshot-from-2022-07-31-00-04-23.png I have a suggestion for you. Use modern possibilities instead of applying functions used in the past to the present. For example, in a world with UTF, ordinary string reversing can result in erroneous results. Also, please don't use pictures, use Markdown instead... SDB@79
Re: Obsecure problem 1
On Saturday, 30 July 2022 at 22:13:55 UTC, pascal111 wrote: Because copying the running window contents is not allowed, I couldn't do it in Code::Blocks. Not allowed? o.O Did you try to select the text and insert it via middle mouse button in another window? Those terminals usually copy the text by selection automatically.
Re: Obsecure problem 1
On Saturday, 30 July 2022 at 21:48:35 UTC, rikki cattermole wrote: It is a pretty straight forward. You tried to access memory out of bounds of the slice. https://github.com/pascal111-fra/D/blob/main/dcollect.d#L34 That for loop is problematic in a number of ways. You should not use int, or uint to index into memory, only size_t should be used. It is an alias to either uint or ulong based upon the size of a pointer. ```d for(size_t i = ch.length - 1; i >= 0; i--) ``` Would be the corrected line. However, it is still not correct, what happens when ch.length is zero? It'll wrap around and become a very large number. That is most likely what happened here. To do this safely in D, use the foreach_reverse statement instead. There are very few reasons to use for loops in D. https://dlang.org/spec/statement.html#foreach-range-statement Adjusted: ```d foreach_reverse(i; 0 .. ch.length) ``` However this is not efficient as you are reallocating constantly. ```d char[] ch_rev; ch_rev.length = ch.length; size_t offset; foreach_reverse(c; ch) ch_rev[offset++] = c; ``` Your suggestion works. It seems a problem with that "for" loop, but I don't know exactly from where it got a 0 or subtracted of 0. I changed data types of some parameters and for loops, and changed that for loop as you suggested: https://github.com/pascal111-fra/D/blob/main/dcollect.d The program works fine now: https://i.postimg.cc/3wkgXmVs/Screenshot-from-2022-07-31-00-04-23.png
Re: Obsecure problem 1
On Saturday, 30 July 2022 at 21:52:42 UTC, frame wrote: On Saturday, 30 July 2022 at 21:24:50 UTC, pascal111 wrote: I've typed a code to enjoy with my library "dcollect", and found non-understandable error: ... Running screen says: https://i.postimg.cc/G3YyCmbF/Screenshot-from-2022-07-30-23-23-59.png Why you don't copy the output instead? Because copying the running window contents is not allowed, I couldn't do it in Code::Blocks. A range violation is the safe error (if bound checking enabled) that is thrown if you access an index of a range or array that is out of bounds. You may try to access an index that is larger than elements in the array. I think you are right.
Re: Obsecure problem 1
On Saturday, 30 July 2022 at 21:24:50 UTC, pascal111 wrote: I've typed a code to enjoy with my library "dcollect", and found non-understandable error: ... Running screen says: https://i.postimg.cc/G3YyCmbF/Screenshot-from-2022-07-30-23-23-59.png Why you don't copy the output instead? A range violation is the safe error (if bound checking enabled) that is thrown if you access an index of a range or array that is out of bounds. You may try to access an index that is larger than elements in the array.
Re: Obsecure problem 1
It is a pretty straight forward. You tried to access memory out of bounds of the slice. https://github.com/pascal111-fra/D/blob/main/dcollect.d#L34 That for loop is problematic in a number of ways. You should not use int, or uint to index into memory, only size_t should be used. It is an alias to either uint or ulong based upon the size of a pointer. ```d for(size_t i = ch.length - 1; i >= 0; i--) ``` Would be the corrected line. However, it is still not correct, what happens when ch.length is zero? It'll wrap around and become a very large number. That is most likely what happened here. To do this safely in D, use the foreach_reverse statement instead. There are very few reasons to use for loops in D. https://dlang.org/spec/statement.html#foreach-range-statement Adjusted: ```d foreach_reverse(i; 0 .. ch.length) ``` However this is not efficient as you are reallocating constantly. ```d char[] ch_rev; ch_rev.length = ch.length; size_t offset; foreach_reverse(c; ch) ch_rev[offset++] = c; ```
Obsecure problem 1
I've typed a code to enjoy with my library "dcollect", and found non-understandable error: module main; import std.stdio; import dcollect; import std.string; import std.conv; int main(string[] args) { string sentence_x, sent_result, token2; string[] sentence_tokens; writeln(strstring(5,"*")," No tail \"s\" ",strstring(5,"*")); writeln; write("Compose a line: "); sentence_x=strip(readln()); sentence_tokens=sentence_x.d_strtok(" ,;.:!?\"'"); foreach(token; sentence_tokens){ token2=token.strrtrim; if(token2[token2.length-1]=='s') token2=strdel(token2, token2.length-1,1); sent_result~=token2~" ";} sent_result.writeln; return 0; } dcollect library: https://github.com/pascal111-fra/D/blob/main/dcollect.d I changed some data types of some functions parameters to "ulong": string strdel(const string ch, ulong x, ulong l ) { string l_ch=ch.strleft(x); string r_ch=ch.strright(ch.length-(x+l)); return (l_ch~=r_ch); } string strleft(const string ch, ulong n) { string ch_sub; ch_sub=ch[0..n]; return ch_sub; } // string strreverse(const string ch) { string ch_rev; for(ulong i=ch.length-1; i>=0; i--) ch_rev~=ch[i]; return ch_rev; } /*/ string strright(const string ch, ulong n) { string ch_sub1, ch_sub2; ch_sub1=strreverse(ch); ch_sub2=strleft(ch_sub1, n); ch_sub1=strreverse(ch_sub2); return ch_sub1; } Running screen says: https://i.postimg.cc/G3YyCmbF/Screenshot-from-2022-07-30-23-23-59.png
Re: Some user-made C functions and their D equivalents
On Saturday, 30 July 2022 at 17:55:02 UTC, pascal111 wrote: I don't understand much the posting details of this forum. https://forum.dlang.org/help#about It's simple: if you want to format/style your posts rather then just using plain text, enable the Markdown option. It's similar to Github-formatting. Otherwise don't, because some tokens trigger a format where it makes no sense. To avoid that, just post in plain text mode by unchecking the option and make use of the preview option too.
Re: Is this a violation of const?
On Saturday, 30 July 2022 at 10:34:09 UTC, ag0aep6g wrote: You're not making sense. Your `s` is mutable, not immutable. You're right! I saw the hole at the end of the tunnel late 😀 But if you compile the example below without the `new operator`, the system does not work and does not give any errors. Why? **Voldermort Type Version:** ```d auto imstr(string str) pure @safe { struct IMSTR { string s; void delegate(string s) @safe update; string toString() const { return s; } } auto s = new IMSTR(str); s.update = (_) { s.s = _; }; return s; } import std.stdio; void main() @safe { immutable auto str = imstr("Test 123"); //str.s = "test"; str.toString.writeln; str.update("TEST A"); str.toString.writeln; str.update("TEST B"); str.toString.writeln; typeid(str).writeln; }/* Prints: Test 123 TEST A TEST B immutable(immutable(onlineapp.imstr(immutable(char)[]).IMSTR)*) */ ``` SDB@79
Re: Some user-made C functions and their D equivalents
On Thursday, 28 July 2022 at 23:08:15 UTC, frame wrote: On Thursday, 28 July 2022 at 20:20:27 UTC, pascal111 wrote: I retyped again some function of C library I made before, but with D code: It's a start but you need to learn. Thanks! I made the equivalent of my C library "collect": https://github.com/pascal111-fra/D/blob/main/dcollect.d - these functions can run into UB if you compile it without bound checking enabled You are right, but I'm still in the beginning to learn all necessary concepts and features I need. - when working with arrays or ranges it's better to use unsigned integers or just use `size_t` which represents unsigned integer for 32 or 64 bit. This avoids negative values and enables the maxmium value which can be provided on the plattform to access the highest element in the array. I tried to use now "uint". - It's sure advanced topic but you should start to check your input from the beginning. Try what happens if you apply negative numbers or invalid offsets ;-) I don't know which client you are using but please have an eye on proper format of your posts - see the "Markdown formatting" or disable the Markdown option below your input. I don't understand much the posting details of this forum. https://forum.dlang.org/help#about
Re: Is this a violation of const?
On 7/30/22 15:19, Salih Dincer wrote: On Saturday, 30 July 2022 at 10:02:50 UTC, Timon Gehr wrote: It's a `const` hole, plain and simple. This code, which consists of 26 lines, does not compile in DMD 2.087. I am getting this error: constHole.d(15): Error: mutable method `source.Updater.opCall` is not callable using a `const` object constHole.d(15):   Consider adding `const` or `inout` to source.Updater.opCall constHole.d(21): Error: function `source.Updater.opCall(string s)` is not callable using argument types `(string*)` constHole.d(21):   cannot pass argument `&s.s` of type `string*` to parameter `string s` SDB@79 Exactly. This is my point. This code does not compile, and neither should the original version, because it's doing basically the same thing.
Re: Is this a violation of const?
On Saturday, 30 July 2022 at 10:02:50 UTC, Timon Gehr wrote: It's a `const` hole, plain and simple. This code, which consists of 26 lines, does not compile in DMD 2.087. I am getting this error: constHole.d(15): Error: mutable method `source.Updater.opCall` is not callable using a `const` object constHole.d(15):Consider adding `const` or `inout` to source.Updater.opCall constHole.d(21): Error: function `source.Updater.opCall(string s)` is not callable using argument types `(string*)` constHole.d(21):cannot pass argument `&s.s` of type `string*` to parameter `string s` SDB@79
Re: Is this a violation of const?
On 30.07.22 09:15, Salih Dincer wrote: It's possible to do this because it's immutable. You don't need an extra update() function anyway. ```d void main() {    auto s = S("test A");    s.update = (_) { s.s = _; };    s.update("test B");    assert(s.s == "test B");    s.s = "test C";    assert(s.s == "test C"); } // No compile error... ``` You're not making sense. Your `s` is mutable, not immutable.
Re: Is this a violation of const?
On 7/30/22 00:16, H. S. Teoh wrote: On Fri, Jul 29, 2022 at 09:56:20PM +, Andrey Zherikov via Digitalmars-d-learn wrote: In the example below `func` changes its `const*` argument. Does this violates D's constness? ```d import std; struct S { string s; void delegate(string s) update; } void func(const S* s) { writeln(*s); s.update("func"); writeln(*s); } void main() { auto s = S("test"); s.update = (_) { s.s = _; }; writeln(s); func(&s); writeln(s); } ``` The output is: ``` S("test", void delegate(string)) const(S)("test", void delegate(string)) const(S)("func", void delegate(string)) S("func", void delegate(string)) ``` At first I thought this was a bug in the const system, It very much is. https://issues.dlang.org/show_bug.cgi?id=9149 (Note that the fix proposed in the first post is not right, it's the call that should be disallowed.) but upon closer inspection, this is expected behaviour. The reason is, `const` guarantees no changes *only on the part of the recipient* of the `const` reference; The delegate _is_ the recipient of the delegate call. The code is calling a mutable method on a `const` receiver. it does not guarantee that somebody else doesn't have a mutable reference to the same data. For the latter, you want immutable instead of const. So in this case, func receives a const reference to S, so it cannot modify S. However, the delegate created by main() *can* modify the data, This delegate is not accessible in `func`, only a `const` version. because it holds a mutable reference to it. So when func invokes the delegate, the delegate modifies the data thru its mutable reference. ... `const` is supposed to be transitive, you can't have a `const` delegate that modifies data through 'its mutable reference'. Had func been declared with an immutable parameter, it would have been a different story, because you cannot pass a mutable argument to an immutable parameter, so compilation would fail. Either s was declared mutable and the delegate can modify it, but you wouldn't be able to pass it to func(), or s was declared immutable and you can pass it to func(), but the delegate creation would fail because it cannot modify immutable. In a nutshell, `const` means "I cannot modify the data", whereas `immutable` means "nobody can modify the data". Apparently small difference, but actually very important. T This is a case of "I am modifying the data anyway, even though am `const`." Delegate contexts are not exempt from type checking. A `const` existential type is still `const`. What the code is doing is basically the same as this: ```d import std; struct Updater{ string *context; void opCall(string s){ *context=s; } } struct S{ string s; Updater update; } void func(const S* s){ writeln(*s); s.update("func"); writeln(*s); } void main(){ auto s = S("test"); s.update = Updater(&s.s); writeln(s); func(&s); writeln(s); } ``` It's a `const` hole, plain and simple.
Re: Is this a violation of const?
On Saturday, 30 July 2022 at 06:04:16 UTC, ag0aep6g wrote: Yes. Here's a modified example to show that you can also violate `immutable` this way: It's possible to do this because it's immutable. You don't need an extra update() function anyway. ```d void main() { auto s = S("test A"); s.update = (_) { s.s = _; }; s.update("test B"); assert(s.s == "test B"); s.s = "test C"; assert(s.s == "test C"); } // No compile error... ``` SDB@79