Conversation
…ragment types; add initial test suite for HttpUrl module.
… with tokenization functionality and tests.
…add comprehensive tests for full URL parsing.
…roved string handling and memory management.
…t and improve query parameter handling
…eadability and maintainability
…ed code reuse and clarity
…tation; update index.html to include new modules
…trictions on embedded procedures
…mproved logging capabilities
…server communication
…ements and add example usage
…rsing and body reading
…or Content-Length
… and add helper functions for better readability and maintainability
…ndling, including body parsing and logging. Update tests to reflect changes in response parsing methods.
… management. Ensure accumulated data is returned if delimiter is not found before socket closure.
…er handling. Enhance logging for socket errors and streamline data extraction logic.
…ing the loop. Retain partial data for subsequent calls if the loop exits due to WouldBlock or Closed.
…t closure without Content-Length. Implement max byte limit and improve error handling.
|
This is interesting. I need to think about this one. I'm OK with wrapping C libraries (I understand how to do that with OBNC) but adding Python into the mix seems to make things more complex (perhaps I miss reading your description?). On my some day maybe list is some sort of generic map/dict like object that can be used in the web context and for mapping data in from structured data formats like JSON or YAML. For my own project interest this would make Oberon-07 a more attractive option. That said being able to spin up an HTTP client also seems really intriguing. Anyhow, let me think on this a bit. Thank you for the submissions. It has encouraged me to get back to this project when I can squeeze some time for it. |
|
Thanks for taking a look at this pull request. The python code is there for testing the http client only. It is not needed for the client, but as the current http client implementation could not handle the complexities of real world http I wanted to provide something for verification, as this could not be really tested in isolation. It could be moved to a separate folder maybe, or we could remove it altogether and just leave instructions in the readme or the module source. As for json and xml these would require either wrapping a c library (jsonc is promising for json, did not research xml in depth in this regard) or for a portable oberon solution write tokenizer, parser, etc. these are more involved tasks, where multiple layers must be designed and implemented l. And for pure http client functionality, wrapping libcurl would be also viable and would enable some use cases (I was thinking about doing this, but I was curious about how usable Oberon would be to do this from scratch. Going on with such decisions would require more strategic planning - what use cases should Artemis enable or support - embedded systems? Small games and tinkering on minimal systems? Writing generic tooling somewhat similar to what go is used for? |
|
Ah that makes sense. I'll try to make some time this weekend to look everything over.
It has been inspiring to see your contributions. All the best, Robert
On July 22, 2025 12:22:17 AM PDT, Erno Szabados ***@***.***> wrote:
erno-szabados left a comment (rsdoiel/Artemis#20)
Thanks for taking a look at this pull request.
The python code is there for testing the http client only. It is not needed for the client, but as the current http client implementation could not handle the complexities of real world http I wanted to provide something for verification, as this could not be really tested in isolation.
It could be moved to a separate folder maybe, or we could remove it altogether and just leave instructions in the readme or the module source.
As for json and xml these would require either wrapping a c library (jsonc is promising for json, did not research xml in depth in this regard) or for a portable oberon solution write tokenizer, parser, etc. these are more involved tasks, where multiple layers must be designed and implemented l.
And for pure http client functionality, wrapping libcurl would be also viable and would enable some use cases (I was thinking about doing this, but I was curious about how usable Oberon would be to do this from scratch.
Going on with such decisions would require more strategic planning - what use cases should Artemis enable or support - embedded systems? Small games and tinkering on minimal systems? Writing generic tooling somewhat similar to what go is used for?
--
Reply to this email directly or view it on GitHub:
#20 (comment)
You are receiving this because you were assigned.
Message ID: ***@***.***>
R. S. Doiel
|
Overview
The goal here is to implement a proof of concept HTTP Client. It works with a simple local python client but not in a real setting (could not handle connection keepalive, for example).
I thought this is a good real world task to validate implemented functions.
Sorry for the big change set, I think there's a lot of useful code. I got bored with the details in the end but wanted to provide it anyway. It could either go to main or to its own feature branch if you find it valuable.
I've found that the mixed use of oberon strings and dstrings is cumbersome, maybe the logger (and other modules) could use extensions to handle dstrings. Deciding what part should rely on the oakwood modules or the new modules was difficult. I think more thought should be given to this, if anyone would like to use this API, as priorities would be different for embedded or lightweight systems and for linux command line tools, just to name a few.
Features
Bug Fixes
I've found some issues with the socket wrapper, a semantic issue and a bug in DString.
Fixed an off-by-one error in
DStrings.Mod'sTrimLeftprocedure and corrected logic inWriteDStringto ensure proper string operations. [1] [2]Corrected a typo in the documentation comment of
WriteFixedinDStrings.Mod.Code Simplifications
Dictionary.Modby removing unnecessary intermediate variables (dictState) in adapter procedures and directly accessing the visitor state. [1] [2]Copilot Updates
.github/copilot-instructions.mdI used github copilot, but the assistance it could provide for a niche language like oberon-07 is limited. Thus the very detailed copilot guidelines..github/instructions/CreateOberonCWrapper.instructions.md..github/instructions/NewOberonModuleCreationOBNC.instructions.mdto provide detailed steps and best practices for creating Oberon modules using the OBNC compiler.