newRPL documentation - Part I available
03-03-2015, 09:48 PM
Post: #1
 Claudio L. Senior Member Posts: 1,081 Joined: Dec 2013
newRPL documentation - Part I available
I've made available the first part of the user-level documentation here: Programming in newRPL Part I
It's a pretty basic RPL tutorial with newRPL features (especially the Variables topic). Feel free to read and comment if something doesn't look right or could be improved.
All the examples can be tried on the latest demo available in sourceforge.

There's other lower-level documents that have been available for quite some time, that are more for developers or simply people interested in how things are put together.
You can find everything here: newRPL Docs.

Claudio
03-12-2015, 08:42 AM (This post was last modified: 03-12-2015 04:15 PM by Ailurus.)
Post: #2
 Ailurus Junior Member Posts: 12 Joined: Mar 2014
RE: newRPL documentation - Part I available
I've read the guide now and gone through the examples you give and I'm really pleased with it. I can only speak as someone who knew how to program already and someone who somewhat knew RPL, but I think it is written in a style that is very accessible to newcomers.

If there's anyone out there who feels like they wanted to learn RPL but haven't yet, I encourage you too take a look at this guide! You don't need a demo of newRPL installed on your computer as it's possible to do the examples right on your 50g calculator.*

I'm thinking that adding some style could maybe add to the readability? Such as having a <kbd>...</kbd> tag around button presses. I also wonder if the smaller font size in the later part of the text is intentional or not?

* As Claudio said, newRPL differs in many ways and this might not be such a good advice.
03-12-2015, 03:43 PM
Post: #3
 Claudio L. Senior Member Posts: 1,081 Joined: Dec 2013
RE: newRPL documentation - Part I available
(03-12-2015 08:42 AM)Ailurus Wrote:  I've read the guide now and gone through the examples you give and I'm really pleased with it. I can only speak as someone who knew how to program already and someone who somewhat knew RPL, but I think it is written in a style that is very accessible to newcomers.

If there's anyone out there who feels like they wanted to learn RPL but haven't yet, I encourage you too take a look at this guide! You don't need a demo of newRPL installed on your computer as it's possible to do the examples right on your 50g calculator.

I'm thinking that adding some style could maybe add to the readability? Such as having a <kbd>...</kbd> tag around button presses. I also wonder if the smaller font size in the later part of the text is intentional or not?

Thanks for the feedback!
I didn't put much attention to formatting. I'd like to have better fonts for the RPL programs, and I have no clue what happened to the font size.
At least I feel encouraged to write the second chapter, now that at least there's one reader! (the zero replies on this post and the hit-count on the website suggested that nobody cared to read it).

Regarding following the examples with a 50g, I strongly disagree with doing that. While the languages are mostly compatible, examples using newRPL specific features will give errors or just behave differently on the 50g and discourage the reader. In this first part, for example, the entire section devoted to local variables diverges from the classic userRPL way.
You can't declare locals anywhere in the code with LSTO on the 50g. Also, you can't sandbox an existing program by creating wrappers with local variables with the same name. Those are new concepts, unheard of in userRPL but they bring a more "modern" way of programming in RPL. None of those examples would work on a 50g.

The next part I'm planning to introduce the different types of objects and enough background for the reader to understand how to use them and the differences with the 50g (believe it or not there are many!).

Thanks again for reading!
03-12-2015, 06:12 PM
Post: #4
 rprosperi Senior Member Posts: 2,083 Joined: Dec 2013
RE: newRPL documentation - Part I available
(03-12-2015 03:43 PM)Claudio L. Wrote:  ...the zero replies on this post and the hit-count on the website suggested that nobody cared to read it).

More readers than you think, but in my case I had not responded. I like it and agree the style and content is conducive for learning RPL.

One small suggesition to consider. Since basically all (at least initially) readers are coming from at least some RPL background, suggest you use some way of indicating those aspects of newRPL whcih differ from classic RPL (didn't think I'd ever use that phrase ). Either a colored font, different type face, asterisks, whatever suits you. This will have the dual effect of highlighting the improvements in newRPL, and also letting folks playing along at home with a 48/49/50 understand why it's not working for them.

I think this will be particularly helpful when you get to more sophisticated topics dealing with Lists, and other more complex object types. This also will inherently handle the "differences from the 50g" you noted you are planning.

Just a thought.

--Bob Prosperi
03-12-2015, 08:27 PM
Post: #5
 Claudio L. Senior Member Posts: 1,081 Joined: Dec 2013
RE: newRPL documentation - Part I available
(03-12-2015 06:12 PM)rprosperi Wrote:
(03-12-2015 03:43 PM)Claudio L. Wrote:  ...the zero replies on this post and the hit-count on the website suggested that nobody cared to read it).

More readers than you think, but in my case I had not responded. I like it and agree the style and content is conducive for learning RPL.

One small suggesition to consider. Since basically all (at least initially) readers are coming from at least some RPL background, suggest you use some way of indicating those aspects of newRPL whcih differ from classic RPL (didn't think I'd ever use that phrase ). Either a colored font, different type face, asterisks, whatever suits you. This will have the dual effect of highlighting the improvements in newRPL, and also letting folks playing along at home with a 48/49/50 understand why it's not working for them.

I think this will be particularly helpful when you get to more sophisticated topics dealing with Lists, and other more complex object types. This also will inherently handle the "differences from the 50g" you noted you are planning.

Just a thought.

Thank you! That's exactly the kind of constructive criticism I'm looking for, your suggestion is not small by any means. You are absolutely right, I need to highlight the differences somehow. I'll figure something out.
03-24-2015, 07:49 PM
Post: #6
 Gjermund Skailand Junior Member Posts: 10 Joined: Dec 2013
RE: newRPL documentation - Part I available
Hi.

I like your simple style for rpl description and examples.

However, for me it would probably be of interrest to add my own objects and libraries in C. I remember looking at the developer docs a while ago, and found it to be a but too terse and technical for a hobbyist like me (I actually learnt C because I wanted to program the hp50g in hpgcc) and would like to see some small but complete examples.
On a sidenote: I could not see if the for-next loop does the testing before executing the loop. I would consider it an improvement if behaviour was changed to test first.
Best regards
Gjermund
03-25-2015, 12:35 AM
Post: #7
 Sylvain Cote Senior Member Posts: 718 Joined: Dec 2013
RE: newRPL documentation - Part I available
Hello Claudio,

My development platform is a MacBookPro running OS/X v10.10.2.
I am using QT Creator 3.3.0 with QT 5.4.0 and Clang 6.0 64 bits (LLVM).

I have tried to compile the source code and I get several errors and lots of warnings.

There are minor warning ...
- passing a char* and casting it as a uint8_t* (BYTEPTR)
-> warning: passing 'char [2]' to parameter of type 'BYTEPTR' (aka 'unsigned char *') converts between pointers to integer types with different sign [-Wpointer-sign]
- several unused parameters
-> warning: unused parameter 'keymsg' [-Wunused-parameter]

There are warnings that should be addressed ...
* missing functions declarations
-> warning: implicit declaration of function 'uiCursorRight' is invalid in C99 [-Wimplicit-function-declaration]
* multiple type definitions and/or same type defined multiple times in different files
-> warning: redefinition of typedef 'HALFWORD' is a C11 feature [-Wtypedef-redefinition]

The errors are related to ... __attribute__((section ...

-> error: argument to 'section' attribute is not valid for this target: mach-o section specifier requires a segment and section separated by a comma
-> #define __READ_ONLY__ __attribute__((section (".rodata")))
-> extern void * __READ_ONLY__ (* mpd_callocfunc)(size_t nmemb, size_t size);

-> error: argument to 'section' attribute is not valid for this target: mach-o section specifier requires a segment and section separated by a comma
-> volatile int __keyb_lock __attribute__((section (".system_globals")));

I do not think LLVM support those type of declarations/attributes/sections, I will investigate.

A short scan through the C code shows clarity and a very well separation of concerns, all in all this seems to be a very nice implementation.

Best regards,

Sylvain
03-26-2015, 03:58 PM
Post: #8
 Claudio L. Senior Member Posts: 1,081 Joined: Dec 2013
RE: newRPL documentation - Part I available
(03-24-2015 07:49 PM)Gjermund Skailand Wrote:  Hi.

I like your simple style for rpl description and examples.

However, for me it would probably be of interrest to add my own objects and libraries in C. I remember looking at the developer docs a while ago, and found it to be a but too terse and technical for a hobbyist like me (I actually learnt C because I wanted to program the hp50g in hpgcc) and would like to see some small but complete examples.
On a sidenote: I could not see if the for-next loop does the testing before executing the loop. I would consider it an improvement if behavior was changed to test first.
Best regards
Gjermund

You are correct, the developer docs were written in a rush to help my then development team-mates get up to speed with the platform. The docs must be very bad since they never coded a single line... and this is entirely my fault, but rest assured the platform is incredibly flexible.
Everything is in separate .c files (called "libraries" for historic reasons, but they are modules), you can add new object types, new commands and pretty much anything you want is doable just by adding a .c file, registering it with the system and writing one function handler (only one).
The system will call your library handler to compile, decompile, display, evaluate, operate upon, run commands, etc.
That handler interface is what I need to write lots of examples on, etc. The only reason I haven't done so yet is because the API itself is not very stable until all the core classes are implemented. For example I haven't defined yet how the libraries will do "pretty-print" display of custom objects wile still being "hardware independent". Just this week I tried to implement matrices, and realized I'll need additional API to tell the decompiler where to find each element within the object data, since matrices are not like lists where I can just let the decompiler make one pass through all the objects.

Regarding FOR/NEXT, for compatibility reasons, it behaves exactly like classic RPL, with the test being done at the end. The problem is that there's no way of knowing when the FOR loop is executed whether you should or not go in.
For example:
Code:
<< 3 1 FOR I I 3 / NEG STEP >>
When you execute the FOR entering the loop, all you know is that you are going from 3 to 1. If the step is positive or negative is unknown until you reach the STEP word and have the actual value in the stack. Only by executing the loop once you'll know if you are decrementing or incrementing that counter. If the step is positive, I>1 would end the loop, but if the step is negative, I>=1 would continue the loop.
Granted, we'd know the increment is +1 if we use NEXT instead of STEP, but then FOR/NEXT would behave different from FOR/STEP, wouldn't be consistent.
03-26-2015, 04:38 PM
Post: #9
 Claudio L. Senior Member Posts: 1,081 Joined: Dec 2013
RE: newRPL documentation - Part I available
(03-25-2015 12:35 AM)Sylvain Cote Wrote:  Hello Claudio,

My development platform is a MacBookPro running OS/X v10.10.2.
I am using QT Creator 3.3.0 with QT 5.4.0 and Clang 6.0 64 bits (LLVM).

I have tried to compile the source code and I get several errors and lots of warnings.

I have just committed to the repository the simulator sources. I did a test and had to change a couple of things for it to compile with Clang, so the old sources you have will not do the magic.
I suggest you clone the new repository in a new folder and start again.
I used nearly the same configuration you have but on FreeBSD and it compiled fine. Bear in mind that there's a couple of issues: newRPL was created for 32-bit platforms, and while it compiles and apparently runs fine on 64-bits, I have not done any checks that it is actually compatible (other than a simple run).
On 64-bit platforms, pointers are 8-bytes instead of 4-bytes, so there could be a few places where this could be a problem (pointer arithmetics). With good coding it shouldn't be, but I haven't checked and there could be an issue in a few places (I hope not too many). The platform itself is quite stable, so if you notice any crashes, it is likely
due to this, please report with me and I'll track it down.
You can build the main .pro file for the GUI demo, or go inside the newrpl directory and open the newrpl-base.pro file to run the old console based demo.
For FreeBSD I had to add a LIBS += ... statement on the .pro files or it wouldn't find the Qt5 libraries. This directory might vary with your installation of Qt5, and you might actually have to remove it (should work out of the box without it, but for some reason my Qt Creator wasn't detecting the Qt5 libraries directly, and manually adding them to the Kit wouldn't let the linker find them after a successful compile).

What you should get when you compile:
* Around 400 warnings are normal, most of them are harmless type casts or redefinitions due to including the same header twice. These will be cleaned up as I go, but there should no errors. Clang has many more warnings than gcc.
* The GUI simulator only responds to the number keys, the dot, the 4 basic operations , Enter and BackSpace for now. Ah, the right cursor does SWAP!!!. The rest is being worked on.
* If you want to play with the RPL language, I recommend you build the text demo to be able to type something other than numbers. It won't take me long to implement the rest of the keys, but it's work in progress. I'm working on some keys with special behavior first, like +/- and EEX keys, proper text editor, etc.
* There's no keyboard drawn on the screen, just the green simulated screen.
* No soft menus (they are drawn as a mock-up, not functional yet).
* An annoying text in the lower-right corner shows which key you pressed (this is for debug only and will be removed as soon as I finish working on the keyboard handlers).
* Errors are displayed during 5 seconds and don't stop you from continuing your work, no need to press anything, just read and keep working until they disappear.

Don't get disappointed with the GUI demo yet, remember it hasn't been released, you are building directly from the development branch where all work is happening. Once there's a release you'll be able to select from the stable tags or the bleeding edge.

Thanks for trying to compile!
Let me know if you can compile the GUI in OSX, it should work fine now.

Claudio
03-27-2015, 01:30 AM (This post was last modified: 03-27-2015 01:30 AM by Han.)
Post: #10
 Han Senior Member Posts: 1,717 Joined: Dec 2013
RE: newRPL documentation - Part I available
I'm getting the same errors with a pull from 9:29PM EST today (MAR 26, 2015).

Code:
../newrpl-sources/newrpl/contrib/mpdecimal-2.4.0/libmpdec/mpdecimal.h:776:15: error: argument to 'section' attribute is not valid for this target: mach-o section specifier requires a segment and section separated by a comma extern void * __READ_ONLY__ (* mpd_callocfunc)(size_t nmemb, size_t size);

Graph 3D | QPI | SolveSys
03-27-2015, 03:19 PM
Post: #11
 Claudio L. Senior Member Posts: 1,081 Joined: Dec 2013
RE: newRPL documentation - Part I available
(03-27-2015 01:30 AM)Han Wrote:  I'm getting the same errors with a pull from 9:29PM EST today (MAR 26, 2015).

Code:
../newrpl-sources/newrpl/contrib/mpdecimal-2.4.0/libmpdec/mpdecimal.h:776:15: error: argument to 'section' attribute is not valid for this target: mach-o section specifier requires a segment and section separated by a comma extern void * __READ_ONLY__ (* mpd_callocfunc)(size_t nmemb, size_t size);

It seems OSX has the __attribute__ 'section' different from all other platforms. It's only needed for the actual firmware, but it's safely ignored by the linker on Windows, Linux and BSD. I've arranged for the section attributes to be removed completely on a PC target. I've also made quite a few changes to improve compatibility with 64-bits in trouble areas.
Pull the repo and try again, hopefully this time it builds on OSX.
03-27-2015, 03:49 PM
Post: #12
 Han Senior Member Posts: 1,717 Joined: Dec 2013
RE: newRPL documentation - Part I available
(03-27-2015 03:19 PM)Claudio L. Wrote:
(03-27-2015 01:30 AM)Han Wrote:  I'm getting the same errors with a pull from 9:29PM EST today (MAR 26, 2015).

Code:
../newrpl-sources/newrpl/contrib/mpdecimal-2.4.0/libmpdec/mpdecimal.h:776:15: error: argument to 'section' attribute is not valid for this target: mach-o section specifier requires a segment and section separated by a comma extern void * __READ_ONLY__ (* mpd_callocfunc)(size_t nmemb, size_t size);

It seems OSX has the __attribute__ 'section' different from all other platforms. It's only needed for the actual firmware, but it's safely ignored by the linker on Windows, Linux and BSD. I've arranged for the section attributes to be removed completely on a PC target. I've also made quite a few changes to improve compatibility with 64-bits in trouble areas.
Pull the repo and try again, hopefully this time it builds on OSX.

Still a reference left (line 68 in sysvars.c) via SCRATCH_MEMORY, defined in hal.h

Graph 3D | QPI | SolveSys
03-27-2015, 04:19 PM
Post: #13
 Claudio L. Senior Member Posts: 1,081 Joined: Dec 2013
RE: newRPL documentation - Part I available
(03-27-2015 03:49 PM)Han Wrote:  Still a reference left (line 68 in sysvars.c) via SCRATCH_MEMORY, defined in hal.h

I thought I had taken care of that, but the #define constant was wrong (actually inconsistent between the 2 projects, GUI and non-GUI).
I fixed that, it should build now (it's hard because I don't have a Mac, so it builds just fine here).
I did notice the text demo crashed on 64-bit when dumping the stack. I'll commit some more fixes during the weekend, but the GUI should run at least.
03-27-2015, 07:08 PM
Post: #14
 Claudio L. Senior Member Posts: 1,081 Joined: Dec 2013
RE: newRPL documentation - Part I available
I committed a few more things that I had on another laptop: matrices should now compile and display on the stack (text demo only).
The text demo doesn't crash on 64-bit systems.
The GUI also supports now the +/- key and the EEX key, so you can type any number now and operate on it.

Claudio.
03-27-2015, 09:05 PM
Post: #15
 Sylvain Cote Senior Member Posts: 718 Joined: Dec 2013
RE: newRPL documentation - Part I available
Hello Claudio,
I will try it Sunday morning.
Thank you for your support.
Sylvain
03-31-2015, 01:50 AM
Post: #16
 Sylvain Cote Senior Member Posts: 718 Joined: Dec 2013
RE: newRPL documentation - Part I available
Hello Claudio,

I can compile and link the code now but it crashes on execution.
The rplInstallLibrary function in QThread is the one causing it.
Same thing for the command line version.

Best regards,

Sylvain

Partial core dump ...
Code:
Process:               newrpl-ui [6080] Path:                  /Volumes/VOLUME/UsersData/*/newrpl-ui.app/Contents/MacOS/newrpl-ui Identifier:            home.sycote.osx.newrpl-ui Version:               ??? Code Type:             X86-64 (Native) Parent Process:        Qt Creator [4884] Responsible:           Qt Creator [4884] User ID:               502 Date/Time:             2015-03-30 21:37:03.110 -0400 OS Version:            Mac OS X 10.10.2 (14C1514) Report Version:        11 Anonymous UUID:        FDD89841-3119-41CC-9021-2170BD6994D4 Time Awake Since Boot: 9900 seconds Crashed Thread:        7  QThread Exception Type:        EXC_BAD_ACCESS (SIGSEGV) Exception Codes:       KERN_INVALID_ADDRESS at 0x000000000d6f5c7c VM Regions Near 0xd6f5c7c: -->      __TEXT                 000000010d57a000-000000010d706000 [ 1584K] r-x/rwx SM=COW  /Volumes/VOLUME/UsersData/*/newrpl-ui.app/Contents/MacOS/newrpl-ui Thread 0:: Dispatch queue: com.apple.main-thread 0   org.qt-project.QtWidgets          0x000000010d896b51 QGestureManager::filterEvent(QWidget*, QEvent*) + 1 1   org.qt-project.QtWidgets          0x000000010d846316 QApplication::notify(QObject*, QEvent*) + 518 2   org.qt-project.QtCore             0x000000010e6c0fb3 QCoreApplication::notifyInternal(QObject*, QEvent*) + 115 3   org.qt-project.QtWidgets          0x000000010d8774fe QWidget::ensurePolished() const + 94 4   org.qt-project.QtWidgets          0x000000010d8775a1 QWidget::ensurePolished() const + 257 5   org.qt-project.QtWidgets          0x000000010d8775a1 QWidget::ensurePolished() const + 257 6   org.qt-project.QtWidgets          0x000000010d88386e QWidget::setVisible(bool) + 926 7   home.sycote.osx.newrpl-ui         0x000000010d57d3a7 main + 87 8   home.sycote.osx.newrpl-ui         0x000000010d57d344 start + 52 Thread 1:: Dispatch queue: com.apple.libdispatch-manager 0   libsystem_kernel.dylib            0x00007fff83562232 kevent64 + 10 1   libdispatch.dylib                 0x00007fff8e363a6a _dispatch_mgr_thread + 52 Thread 2: 0   libsystem_kernel.dylib            0x00007fff8356194a __workq_kernreturn + 10 1   libsystem_pthread.dylib           0x00007fff8312a40d start_wqthread + 13 Thread 3: 0   libsystem_kernel.dylib            0x00007fff8356194a __workq_kernreturn + 10 1   libsystem_pthread.dylib           0x00007fff8312a40d start_wqthread + 13 Thread 4: 0   libsystem_kernel.dylib            0x00007fff8356194a __workq_kernreturn + 10 1   libsystem_pthread.dylib           0x00007fff8312a40d start_wqthread + 13 Thread 5: 0   libsystem_kernel.dylib            0x00007fff8356194a __workq_kernreturn + 10 1   libsystem_pthread.dylib           0x00007fff8312a40d start_wqthread + 13 Thread 6: Thread 7 Crashed:: QThread 0   home.sycote.osx.newrpl-ui         0x000000010d5b52cc rplInstallLibrary + 124 1   home.sycote.osx.newrpl-ui         0x000000010d5b5c47 rplInit + 327 2   home.sycote.osx.newrpl-ui         0x000000010d5f7d87 main_virtual + 135 3   home.sycote.osx.newrpl-ui         0x000000010d5f7ee6 startup + 86 4   home.sycote.osx.newrpl-ui         0x000000010d5f8041 RPLThread::run() + 17 5   org.qt-project.QtCore             0x000000010e4b7393 QThreadPrivate::start(void*) + 339 6   libsystem_pthread.dylib           0x00007fff8312c268 _pthread_body + 131 7   libsystem_pthread.dylib           0x00007fff8312c1e5 _pthread_start + 176 8   libsystem_pthread.dylib           0x00007fff8312a41d thread_start + 13 Thread 7 crashed with X86 Thread State (64-bit):   rax: 0x000000000d6f5c7c  rbx: 0x000000010d711b98  rcx: 0x000000000d6f5c7c  rdx: 0x0000000000000000   rdi: 0x000000010d5b3f70  rsi: 0x000000010d711af0  rbp: 0x00000001152e7d70  rsp: 0x00000001152e7d10    r8: 0x000000010d711b90   r9: 0x000000010d70bda0  r10: 0x000000010d711b88  r11: 0x000000010d711b80   r12: 0x000000010d70bdb8  r13: 0x000000010d711ae8  r14: 0x000000010d70cad8  r15: 0x000000010d70bdd8   rip: 0x000000010d5b52cc  rfl: 0x0000000000010202  cr2: 0x000000000d6f5c7c    Logical CPU:     1 Error Code:      0x00000004 Trap Number:     14
03-31-2015, 05:51 PM
Post: #17
 Claudio L. Senior Member Posts: 1,081 Joined: Dec 2013
RE: newRPL documentation - Part I available
(03-31-2015 01:50 AM)Sylvain Cote Wrote:  Hello Claudio,

I can compile and link the code now but it crashes on execution.
The rplInstallLibrary function in QThread is the one causing it.
Same thing for the command line version.

I just looked at the code. Yes, I see a problem with the way pointers are being passed in the rplInstallLibrary() function that would crash a 64-bit system when Address Space Randomization is enabled (if the higher 32-bit of the pointer are zero it would work, which is why it didn't crash on my tests). I have to fix that.

Thanks for the feedback!

Claudio
04-01-2015, 12:55 AM
Post: #18
 Claudio L. Senior Member Posts: 1,081 Joined: Dec 2013
RE: newRPL documentation - Part I available
(03-31-2015 05:51 PM)Claudio L. Wrote:  I have to fix that.

FYI, I just committed the fix to the repository.

Claudio
04-01-2015, 04:41 AM (This post was last modified: 04-01-2015 04:43 AM by Han.)
Post: #19
 Han Senior Member Posts: 1,717 Joined: Dec 2013
RE: newRPL documentation - Part I available
(04-01-2015 12:55 AM)Claudio L. Wrote:
(03-31-2015 05:51 PM)Claudio L. Wrote:  I have to fix that.

FYI, I just committed the fix to the repository.

Claudio

Most recent commit enables the GUI to work, but I get the following crash when pressing the ENTER (i.e. RETURN) key after simply inputting a few numerical digits. Also, the entry line shows a blinking/highlighted 0 as a cursor. Is this intended?

The crash doesn't happen on the non-GUI version.

Code:
Crashed Thread:  5  QThread Exception Type:  EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000217c48 VM Regions Near 0x217c48: -->      __TEXT                 0000000100000000-000000010018c000 [ 1584K] r-x/rwx SM=COW  /Users/USER/*/newrpl-ui.app/Contents/MacOS/newrpl-ui Thread 0:: Dispatch queue: com.apple.main-thread 0   libsystem_kernel.dylib            0x00007fff892cba1a mach_msg_trap + 10 1   libsystem_kernel.dylib            0x00007fff892cad18 mach_msg + 64 2   com.apple.CoreFoundation          0x00007fff8e575f15 __CFRunLoopServiceMachPort + 181 3   com.apple.CoreFoundation          0x00007fff8e575539 __CFRunLoopRun + 1161 4   com.apple.CoreFoundation          0x00007fff8e574e75 CFRunLoopRunSpecific + 309 5   com.apple.HIToolbox               0x00007fff90863a0d RunCurrentEventLoopInMode + 226 6   com.apple.HIToolbox               0x00007fff908637b7 ReceiveNextEventCommon + 479 7   com.apple.HIToolbox               0x00007fff908635bc _BlockUntilNextEventMatchingListInModeWithFilter + 65 8   com.apple.AppKit                  0x00007fff8bc6024e _DPSNextEvent + 1434 9   com.apple.AppKit                  0x00007fff8bc5f89b -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122 10  com.apple.AppKit                  0x00007fff8bc5399c -[NSApplication run] + 553 11  libqcocoa.dylib                   0x00000001044192a7 QCocoaEventDispatcher::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 2391 12  QtCore                            0x0000000100f8b05d QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 397 13  QtCore                            0x0000000100f8e162 QCoreApplication::exec() + 354 14  @BUNDLEIDENTIFIER@                0x0000000100003451 main + 97 (main.cpp:10) 15  @BUNDLEIDENTIFIER@                0x00000001000033e4 start + 52 Thread 1: 0   libsystem_kernel.dylib            0x00007fff892cfe6a __workq_kernreturn + 10 1   libsystem_pthread.dylib           0x00007fff87788f08 _pthread_wqthread + 330 2   libsystem_pthread.dylib           0x00007fff8778bfb9 start_wqthread + 13 Thread 2:: Dispatch queue: com.apple.libdispatch-manager 0   libsystem_kernel.dylib            0x00007fff892d0662 kevent64 + 10 1   libdispatch.dylib                 0x00007fff8e6f0421 _dispatch_mgr_invoke + 239 2   libdispatch.dylib                 0x00007fff8e6f0136 _dispatch_mgr_thread + 52 Thread 3: 0   libsystem_kernel.dylib            0x00007fff892cfe6a __workq_kernreturn + 10 1   libsystem_pthread.dylib           0x00007fff87788f08 _pthread_wqthread + 330 2   libsystem_pthread.dylib           0x00007fff8778bfb9 start_wqthread + 13 Thread 4: 0   libsystem_kernel.dylib            0x00007fff892cfe6a __workq_kernreturn + 10 1   libsystem_pthread.dylib           0x00007fff87788f08 _pthread_wqthread + 330 2   libsystem_pthread.dylib           0x00007fff8778bfb9 start_wqthread + 13 Thread 5 Crashed:: QThread 0   @BUNDLEIDENTIFIER@                0x000000010001825c rplStrLen + 12 (lib-24-string.c:82) 1   @BUNDLEIDENTIFIER@                0x000000010000919a endCmdLineAndCompile + 74 (hal_keyboard.c:373) 2   @BUNDLEIDENTIFIER@                0x00000001000096c1 enterKeyHandler + 113 (hal_keyboard.c:539) 3   @BUNDLEIDENTIFIER@                0x000000010000a26f halDoDefaultKey + 111 (hal_keyboard.c:887) 4   @BUNDLEIDENTIFIER@                0x000000010000a39e halProcessKey + 238 (hal_keyboard.c:917) 5   @BUNDLEIDENTIFIER@                0x000000010000a3df halOuterLoop + 47 (hal_keyboard.c:981) 6   @BUNDLEIDENTIFIER@                0x000000010007e016 main_virtual + 326 (boot.c:50) 7   @BUNDLEIDENTIFIER@                0x000000010007e0b6 startup + 86 (boot.c:95) 8   @BUNDLEIDENTIFIER@                0x000000010007e211 RPLThread::run() + 17 (rplthread.cpp:17) 9   QtCore                            0x0000000100da5e60 QThreadPrivate::start(void*) + 352 10  libsystem_pthread.dylib           0x00007fff87787899 _pthread_body + 138 11  libsystem_pthread.dylib           0x00007fff8778772a _pthread_start + 137 12  libsystem_pthread.dylib           0x00007fff8778bfc9 thread_start + 13 Thread 6: 0   libsystem_kernel.dylib            0x00007fff892cfe6a __workq_kernreturn + 10 1   libsystem_pthread.dylib           0x00007fff87788f08 _pthread_wqthread + 330 2   libsystem_pthread.dylib           0x00007fff8778bfb9 start_wqthread + 13 Thread 7: 0   libsystem_kernel.dylib            0x00007fff892cfe6a __workq_kernreturn + 10 1   libsystem_pthread.dylib           0x00007fff87788f08 _pthread_wqthread + 330 2   libsystem_pthread.dylib           0x00007fff8778bfb9 start_wqthread + 13 Thread 8: 0   libsystem_kernel.dylib            0x00007fff892cfe6a __workq_kernreturn + 10 1   libsystem_pthread.dylib           0x00007fff87788f08 _pthread_wqthread + 330 2   libsystem_pthread.dylib           0x00007fff8778bfb9 start_wqthread + 13 Thread 9: 0   libsystem_kernel.dylib            0x00007fff892cfe6a __workq_kernreturn + 10 1   libsystem_pthread.dylib           0x00007fff87788f08 _pthread_wqthread + 330 2   libsystem_pthread.dylib           0x00007fff8778bfb9 start_wqthread + 13 Thread 10: 0   libsystem_kernel.dylib            0x00007fff892cfe6a __workq_kernreturn + 10 1   libsystem_pthread.dylib           0x00007fff87788f08 _pthread_wqthread + 330 2   libsystem_pthread.dylib           0x00007fff8778bfb9 start_wqthread + 13 Thread 11: 0   libsystem_kernel.dylib            0x00007fff892cba1a mach_msg_trap + 10 1   libsystem_kernel.dylib            0x00007fff892cad18 mach_msg + 64 2   com.apple.CoreFoundation          0x00007fff8e575f15 __CFRunLoopServiceMachPort + 181 3   com.apple.CoreFoundation          0x00007fff8e575539 __CFRunLoopRun + 1161 4   com.apple.CoreFoundation          0x00007fff8e574e75 CFRunLoopRunSpecific + 309 5   com.apple.AppKit                  0x00007fff8be0005e _NSEventThread + 144 6   libsystem_pthread.dylib           0x00007fff87787899 _pthread_body + 138 7   libsystem_pthread.dylib           0x00007fff8778772a _pthread_start + 137 8   libsystem_pthread.dylib           0x00007fff8778bfc9 thread_start + 13 Thread 5 crashed with X86 Thread State (64-bit):   rax: 0x0000000100217c48  rbx: 0x00000001015ae5c0  rcx: 0x0000000000217c48  rdx: 0x0000000000000000   rdi: 0x0000000000217c48  rsi: 0x0000000000000001  rbp: 0x000000010a304cf0  rsp: 0x000000010a304cf0    r8: 0x0000000000000000   r9: 0x00000000000f4240  r10: 0x0000000000000001  r11: 0x0000000000000008   r12: 0x00000001014613e0  r13: 0x0000000004000000  r14: 0x000000010a305000  r15: 0x00007fff5fbffc28   rip: 0x000000010001825c  rfl: 0x0000000000010206  cr2: 0x0000000000217c48    Logical CPU:     6 Error Code:      0x00000004 Trap Number:     14

Graph 3D | QPI | SolveSys
04-01-2015, 05:50 PM
Post: #20
 Claudio L. Senior Member Posts: 1,081 Joined: Dec 2013
RE: newRPL documentation - Part I available
(04-01-2015 04:41 AM)Han Wrote:  Most recent commit enables the GUI to work, but I get the following crash when pressing the ENTER (i.e. RETURN) key after simply inputting a few numerical digits. Also, the entry line shows a blinking/highlighted 0 as a cursor. Is this intended?

The crash doesn't happen on the non-GUI version.

Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000217c48

__TEXT 0000000100000000-000000010018c000 [ 1584K] r-x/rwx SM=COW

It seems there's more cases of 64-bit issues than I thought. Clearly the program was loaded above the 32-bit limit (per the TEXT addresses above), and the invalid address has the 1 removed from the high 32-bit word, consequence of a pointer getting truncated to 32-bits. I'll eventually track down all the bad cases, but I'd much rather put my effort in making it work on the calculator rather than a 64-bit platform.
I'd suggest for the time being, if you want to try the demo, do it on a VM with a 32-bit operating system (or on Windows, since mingw packaged with Qt Creator is 32-bit only).

Now regarding the cursor, it's a D, not an O, and it's intentional. The cursor letter will change according to the mode (ALG, PRG, etc.). This used to be in the status area, but I think this information is more useful right in front of your eyes.
"D" stands for "direct", since most keys are executed directly when pressed (but I'm open to suggestions for a better letter, I don't like the D much).
"P" will be in PRG mode, where most keys will add an entire word to the command line
"A" will be ALG mode, where the word is inserted as a function and without the separating spaces.
"L" or "C" will be used in alpha mode to indicate lowercase/capitals.

Claudio
 « Next Oldest | Next Newest »

User(s) browsing this thread: 1 Guest(s)