Re: Symmetry Autumn of Code
On Wednesday, 18 July 2018 at 10:42:04 UTC, Andre Pany wrote: On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/ Another proposal: Adding D support to gRPC I started to add D support to gRPC but paused it due to lack of knowledge and time. One solution would be to add a D wrapper to https://github.com/grpc/grpc/tree/master/src by making use of the C interface of gRPC (https://github.com/grpc/grpc/tree/master/include/grpc). As template e.g. C++ or python could be used (https://github.com/grpc/grpc/tree/master/src). Kind regards André Juniper have an alpha C higher interface on top of the low level C core grpc API. It didn't look too bad, but I didn't have time to finish what I started (making a crude D grpc API). https://github.com/Juniper/grpc-c
Re: Symmetry Autumn of Code
On Monday, 23 July 2018 at 13:02:33 UTC, Zheng (Vic) Luo wrote: Another issue of this program is that me, as an incoming graduate in the U.S., are prohibited to "work" in my first school year. (that law doesn't affect GSoC since summer is considered as the second school year). I'm not sure whether contributing to open-source projects is considered as "work" here. There are some legal issues related. I'm looking forward to some clarifications like (https://developers.google.com/open-source/gsoc/faq#is_gsoc_considered_an_internship_a_job_or_any_form_of_employment) stating that this program is an "employment" or not. I'm not an attorney working on immigration law, but Symmetry is not a US company AFAIK, so I don't see how that is relevant. Of course you should check with someone with appropriate expertise first.
Re: Blogpost about the T.init problem
On Wednesday, 11 July 2018 at 07:30:59 UTC, FeepingCreature wrote: To reproduce the format issue, try to print the struct with writefln!"%s"(MyDomainType()). I implemented the compile time format string checking by evaluating `format(fmtStr, Args.init)` at compile time and seeing if an exception was thrown. So the above problem could be worked around by guarding the invariant test with a check that CTFE is not active.
Re: Symmetry Autumn of Code
On Monday, 23 July 2018 at 13:02:33 UTC, Zheng (Vic) Luo wrote: Another issue of this program is that me, as an incoming graduate in the U.S., are prohibited to "work" in my first school year. (that law doesn't affect GSoC since summer is considered as the second school year). I'm not sure whether contributing to open-source projects is considered as "work" here. There are some legal issues related. I'm looking forward to some clarifications like (https://developers.google.com/open-source/gsoc/faq#is_gsoc_considered_an_internship_a_job_or_any_form_of_employment) stating that this program is an "employment" or not. I can't definitively answer whether not the U.S. government would consider it work, but I can tell you that neither Symmetry nor the D Language Foundation consider it employment; they view it just as Google does. I'll add that to the FAQ.
Re: Symmetry Autumn of Code
On Monday, 23 July 2018 at 10:24:14 UTC, Ecstatic Coder wrote: But this BetterC minimalistic standard library (allocations, arrays, strings, slices, maps) is something which can be reused by many similar hardware-level projects. This is a project on its own, and as I said, I think it should better be provided to the candidate so he can use his development time on developing the rasterizer, and, if there is enough time, a minimalistic nuklear-like gui system over it to demonstrate its performance and usefulness. Indeed, having to port the druntime to new hardware is definitely not in scope. I can't anticipate what features of the language the developer will employ, but as long as they stay within the -betterC subset of the language, I think it will be portable to something like that used in https://github.com/JinShil/stm32f42_discovery_demo Even if it isn't portable, if it compiles and runs in -betterC on a PC, it will still be an excellent foundation to build on, and I'd still call it a success. Mike
Re: Symmetry Autumn of Code
On Monday, 23 July 2018 at 09:52:54 UTC, Zheng (Vic) Luo wrote: Regarding floating point operations, I plan to use dmd.builtins/ldc.builtins instead of linking with libm. That reminds me. Something else to consider is that some of these microcontrollers don't have FPUs. Graphics libraries designed for microcontrollers often use fixed-point math as a lowest common denominator. I think, given the features of D, fixed-point or floating point could be selected at compile-time. But, I don't wish to expand the scope of the project. An all-floating point library would be fine, IMO, and fixed-poing math could be added to the library in a future iteration. Mike
Re: Symmetry Autumn of Code
On Monday, 23 July 2018 at 08:08:03 UTC, Mike Franklin wrote: On Monday, 23 July 2018 at 06:24:04 UTC, Zheng (Vic) Luo wrote: Moreover, The term "dependency-free" in the project description often confuses me, because as a hardware-agnostic library the project does have to depend on external implementations like "sin"/"memset" or even "thread_start", and I'm not sure which kind of dependency is proper for this project: Should we assume a multi-threading model? Should this library rely on "malloc"/"free"? Correct me if my understanding is wrong since I had few experience on embedded programming. There is more to this project than just getting a software rasterizer in D. Part of the goal is to demonstrate D as a formidable alternative to C in micrcontroller firmware programming. D will never achieve that notoriety if it's always depending on C, the C runtime, the C standard library, or some library implemented in C. So, IMO, if you need to link in a library or object file that was not compiled from D code, then you're cheating. This is also one of the reasons why I suggested re-implementing software building blocks such as `memcpy`, `memset`, `malloc`, `free`, etc. in D as another potential project for the Autumn of Code. So, to keep this software rasterizer project within scope, I suggest creating naive implementations of those functions in D for now to stay true to spirit of the project (no dependencies, everything in D), and "make the point". You can those software building blocks in their own module, and let the user of the software rasterizer library link it their own implementation if they wish to deviate from the spirit of the proposal. Mike I agree But this BetterC minimalistic standard library (allocations, arrays, strings, slices, maps) is something which can be reused by many similar hardware-level projects. This is a project on its own, and as I said, I think it should better be provided to the candidate so he can use his development time on developing the rasterizer, and, if there is enough time, a minimalistic nuklear-like gui system over it to demonstrate its performance and usefulness.
Re: Symmetry Autumn of Code
On Monday, 23 July 2018 at 09:09:40 UTC, Mike Franklin wrote: On Sunday, 22 July 2018 at 17:12:31 UTC, Ecstatic Coder wrote: 2/ Nuklear (https://github.com/vurtun/nuklear) Reading the documentation for Nuklear, I found this: https://rawgit.com/vurtun/nuklear/master/doc/nuklear.html#drawing To draw all draw commands accumulated over a frame you need your own render backend able to draw a number of 2D primitives. This includes at least filled and stroked rectangles, circles, text, lines, triangles and scissors That's basically what the Autumn of Code proposal would like to have built in D: A rasterizer with fundamental drawing primitives. So, it seems Nuklear is a library intended to be built on top of the proposed rasterizer. Mike +1 Then I agree that Antigrain is probably the best reference code for the antialiased renderer, as its code is small, very complete (ttf/gsv/raster fonts, top quality antialiasing, etc) and reasonably fast. IMO the better-C standard library runtime should be provided to the developer in charge of developing that rasterizer.
Re: Symmetry Autumn of Code
On Monday, 23 July 2018 at 08:08:03 UTC, Mike Franklin wrote: So, IMO, if you need to link in a library or object file that was not compiled from D code, then you're cheating. This is also one of the reasons why I suggested re-implementing software building blocks such as `memcpy`, `memset`, `malloc`, `free`, etc. in D as another potential project for the Autumn of Code. So, to keep this software rasterizer project within scope, I suggest creating naive implementations of those functions in D for now to stay true to spirit of the project (no dependencies, everything in D), and "make the point". You can those software building blocks in their own module, and let the user of the software rasterizer library link it their own implementation if they wish to deviate from the spirit of the proposal. That's actually what I am doing now. Currently I wrote a short script to ensure the symbols in the main project within a subset (https://github.com/htfy96/rasterizer-d-embed/blob/master/check-no-und-symbols.sh). I also plan to create some basic dependency-free building blocks like memcpy/memset/memcmp (already implemented in https://github.com/htfy96/d-rlib) and malloc/free (maybe reusing some building blocks from std.experimental.allocator?) in separate projects. Regarding floating point operations, I plan to use dmd.builtins/ldc.builtins instead of linking with libm. Above this well-defined set of primitives, the core rasterizer will be built, so that users can plug in their own implementations or use the default implementation when libc/libm is linked.
Re: Symmetry Autumn of Code
On Sunday, 22 July 2018 at 17:12:31 UTC, Ecstatic Coder wrote: 2/ Nuklear (https://github.com/vurtun/nuklear) Reading the documentation for Nuklear, I found this: https://rawgit.com/vurtun/nuklear/master/doc/nuklear.html#drawing To draw all draw commands accumulated over a frame you need your own render backend able to draw a number of 2D primitives. This includes at least filled and stroked rectangles, circles, text, lines, triangles and scissors That's basically what the Autumn of Code proposal would like to have built in D: A rasterizer with fundamental drawing primitives. So, it seems Nuklear is a library intended to be built on top of the proposed rasterizer. Mike
Re: Symmetry Autumn of Code
On Monday, 23 July 2018 at 06:24:04 UTC, Zheng (Vic) Luo wrote: Should we assume a multi-threading model? I say, no. To get threads on microcontrollers, you typically first need to implement a Real-time Operating System (RTOS). If you want to implement an RTOS in D, and then build the rasterizer on that, that would be very cool!but also very challenging ;-) Mike
Re: Symmetry Autumn of Code
On Monday, 23 July 2018 at 08:08:03 UTC, Mike Franklin wrote: You can those software building blocks in their own module, and let the user of the software rasterizer library link it their own implementation if they wish to deviate from the spirit of the proposal. Yikes! too many typos there. It should say... You can put those software building blocks in their own module, and let the user of the software rasterizer library link in their own implementation if they wish to deviate from the spirit of the proposal. Mike
Re: Symmetry Autumn of Code
On Monday, 23 July 2018 at 06:24:04 UTC, Zheng (Vic) Luo wrote: Moreover, The term "dependency-free" in the project description often confuses me, because as a hardware-agnostic library the project does have to depend on external implementations like "sin"/"memset" or even "thread_start", and I'm not sure which kind of dependency is proper for this project: Should we assume a multi-threading model? Should this library rely on "malloc"/"free"? Correct me if my understanding is wrong since I had few experience on embedded programming. There is more to this project than just getting a software rasterizer in D. Part of the goal is to demonstrate D as a formidable alternative to C in micrcontroller firmware programming. D will never achieve that notoriety if it's always depending on C, the C runtime, the C standard library, or some library implemented in C. So, IMO, if you need to link in a library or object file that was not compiled from D code, then you're cheating. This is also one of the reasons why I suggested re-implementing software building blocks such as `memcpy`, `memset`, `malloc`, `free`, etc. in D as another potential project for the Autumn of Code. So, to keep this software rasterizer project within scope, I suggest creating naive implementations of those functions in D for now to stay true to spirit of the project (no dependencies, everything in D), and "make the point". You can those software building blocks in their own module, and let the user of the software rasterizer library link it their own implementation if they wish to deviate from the spirit of the proposal. Mike
Re: Symmetry Autumn of Code
On Monday, 23 July 2018 at 06:00:14 UTC, Zheng (Vic) Luo wrote: Thank you for the suggestion. Previously I interned at a VR company and had some experiences writing code related to graphics, but I don't have any experience on embedded system programming, so I was wondering that do I need to buy a microcontroller or just testing it on PC would be enough? If it's the former one, could you give some suggestions on the starter kit? Well, I won't be the one paying you, and I don't think I'll be the one evaluating your work, so I don't think my opinion matters, but as the one who proposed the idea, I'll just explain my point of view. Microcontrollers have limited CPU and memory resources. Generally, they operate by filling a dedicated buffer in RAM (width * height * pixel_format_size) with pixel data. The size and format of the pixel data is generally decided at compile-time based on the needs of the application. Some microcontrollers have a dedicated hardware peripheral to aid in the blitting and blending of pixel data, but most don't. So, for all intents and purposes, this project is a software rasterizer in D; you definitely won't find any CUDA cores here. Understanding the capabilities and limitations of the microcontrollers will give you some perspective and understanding about the design tradeoffs you will most certainly need to make, but, once you have that perspective, in the end, you're just filling a buffer with pixel data, and I don't see why one couldn't do the vast majority (if not all) of development for that on their PC. That being said, getting a low-speed MCU with as little memory as 256KB animating an LCD display can be a thrilling experience. If you're interested, I suggest obtaining one of the STM32 Discovery Kits with a built-in LCD screen. See https://www.st.com/en/evaluation-tools/stm32-mcu-discovery-kits.html?querycriteria=productId=LN1848 (Typically one ofSTM32F4 or STM32F7 models) This is the one that I have, and it only costs about $30: https://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-discovery-kits/32f429idiscovery.html#samplebuy-scroll Furthermore, I've already created the platform code for you at https://github.com/JinShil/stm32f42_discovery_demo, so you should just need to import your library to main.d and try it out. Mike
Re: Symmetry Autumn of Code
On Sunday, 22 July 2018 at 17:12:31 UTC, Ecstatic Coder wrote: I'm interested in the "Graphics library for resource constrained embedded systems" project and have some spare time this autumn, but I have some questions: - Does this project aim at creating a hardware-agnostic rasterizer supporting a few primitives like https://skia.org/ or implementing a full GUI library like emWin rendering widget and handling I/O events such as mouse? The latter one sounds a little bit challenging to finish in four months - In the past year I primarily wrote C++ and don't have much experiences with production-level D programming, can I get involved into this program? Thanks IMHO no need to reinvent the wheel for that. You can probably do both in four months, if you just "port" (separately) and bind the code of the two following libraries : 1/ swGL (https://github.com/h0MER247/swGL) 2/ Nuklear (https://github.com/vurtun/nuklear) They have a very open design, and are already quite well optimized for speed and memory consumption. Moreover this would allow the D port of the Nuklear library to also use a hardware accelerated renderer on desktop platforms. Nice isn't it ? And I'd be glad to mentor you on this :) Thanks! Porting seems to be easier than creating a library from scratch. The Nuklear library looks like a great candidate for porting since it only has a few external dependencies. swGL, however, depends on a large set of C++ standard library and threading model, which makes it difficult to create a dependency-free port. Moreover, The term "dependency-free" in the project description often confuses me, because as a hardware-agnostic library the project does have to depend on external implementations like "sin"/"memset" or even "thread_start", and I'm not sure which kind of dependency is proper for this project: Should we assume a multi-threading model? Should this library rely on "malloc"/"free"? Correct me if my understanding is wrong since I had few experience on embedded programming.
Re: Symmetry Autumn of Code
On Sunday, 22 July 2018 at 22:07:00 UTC, Mike Franklin wrote: The software should be efficient enough to use on embedded systems like https://github.com/JinShil/stm32f42_discovery_demo Under that constraint, you'd probably want to try to accomplish the task with the -betterC-like subset of the language (https://dlang.org/spec/betterc.html). That being said, there's no reason the software couldn't be used on a PC with resources to spare, and it would probably be easier to do the development on a PC and just verify the implementation on an microcontroller periodically. I, myself, don't have much experience in graphics, so I don't know if I'd be a very good mentor, but if you have any questions about the goal or use case for the project, let me know. Thank you for the suggestion. Previously I interned at a VR company and had some experiences writing code related to graphics, but I don't have any experience on embedded system programming, so I was wondering that do I need to buy a microcontroller or just testing it on PC would be enough? If it's the former one, could you give some suggestions on the starter kit?
