User Details
- Office Hours
- Sun 3:30pm-5pm, Tue-Thurs 3:30pm-5pm, Fri 11am-12pm.
- Time Zone
- EST (UTC-05:00)
- Location
- Brooklyn, New York
- Nickname
- Moshe
- School
- Central Yeshiva Tomchei Tmimim Lubavitz
- DEV
- https://dev.to/uminer
- Github Account
- https://github.com/mosheduminer
- Stack Overflow
- https://stackoverflow.com/users/12058591/foolswisdom
- Operating System
- Windows 10, Ubuntu 19.10
- Alternative Species
- Leopard
- Favorite Color
- Dark Gray (#A9A9A9)
- Listening To...
- http://musicforprogramming.net/ - that stuff is great
- Working on...
- [SirixDB Frontend](https://github.com/sirixdb/sirix-web-frontend). And writing jewish legal analysis
- Coffee Order
- Black without the coffe
- Pizza Order
- Olive slices only
- Studying
- Compilers, Talmud.
- Hobbies
- Bicycle, just hang out
- Other Vehicle
- Project Orion (1950s)
- Alternative Time Period
- High Middle Ages (Spain? Maybe Provence)
- User Since
- Nov 19 2019, 12:08 PM (174 w, 5 d)
Jan 30 2020
Well, I typically don't think of a null byte as part of a string, except with c style strings. Does onestring need the null byte? I understand that std::string allows for null inside the string, is that correct?
You're technically right, I think. I wasn't thinking of the null terminator. I don't think this causing problems, but it was found during debugging and I thought it was a bug. I this could be closed then?
Jan 19 2020
- initial StaticLayer
Jan 18 2020
Well, it seems that the main downside is dropping onestring, which I guess isn't so important. I think that a testing framework should be its own library, not bundled with data structures, so I guess goldilocks should be independent.
Jan 16 2020
Jan 14 2020
- Fix CMakeLests
- remove parser code
Jan 11 2020
How about Tuesday 4 PM EST (1 PM PST)?
@jcmcdonald, I am at a loss at how to proceed with the RIFTParser. I assume the parser should return the instantiated objects, but this requires a function that can return any kind of object, which gets into all kinds of complications, starting from the function signature.
Jan 9 2020
- fixed comparison of different integer signs
- finished skeleton for RIFTParser
Jan 8 2020
- Fixed lexer's data reading. Fixed bad file reading in test. Removed pointers so FlexArray should work.
Dec 20 2019
Dec 19 2019
Dec 18 2019
When running the following code (nextToken returns a shared_ptr):
Dec 8 2019
Delayed due to unexpected behavior.
Dec 3 2019
Dec 1 2019
Nov 29 2019
Token RIFTLexer::nextToken() { std::byte code; do { code = input->at(pos); switch (code) { case RIFTCodes::EndFile: // error on this line break; /*code*/ } }
Thank you. However, despite the overload, I am still getting a this constant expression has type "RIFTCodes" instead of the required "std::byte" type error.
Nov 27 2019
Nov 24 2019
If so, it seems to me that this is primarily a serialization task, rather then an interpreter task. If so, it would seem that serialization should be handled by serialize/deserialize methods on the classes that need to be instantiated, merely that this task is merely for parsing the RIFT file and calling the appropriate APIs. Is that correct?