Menu
▾
▴
powermops-beta
|
From: Nao S. <sac...@yb...> - 2005-12-20 13:51:21
Attachments:
CocoaCalls
WebKit-B
|
Hi Mike and All, I downloaded PowerMops64-6 and tried to build 32-bit PowerMops (64bit?/MachO?= false/true, false/false). But it failed because of a missing source file "Processes". After adding the file, PowerMops could be built and run. PowerMops itself seems to be OK, but "CocoaCalls" should be modified for Mach-O (conditional compiling). I attached modified "CocoaCalls". The distribution includes "WebKit-B" in "Cocoa Calls demo folder", which is a simple web browser a bit progressed from "webKitTest" in that it implements delegate methods from PowerMops. But by some reason it crashes on drawing a web page. I fixed and attached it on this mail (file "WebKit-B"). That's all at present. |
|
From: Mike H. <mik...@bi...> - 2005-12-20 22:07:46
|
Hi Nao,
Many thanks for the great work, as usual!
-- Mike.
>
> I downloaded PowerMops64-6 and tried to build 32-bit PowerMops
> (64bit?/MachO?= false/true, false/false).
> But it failed because of a missing source file "Processes".
> After adding the file, PowerMops could be built and run.
>
> PowerMops itself seems to be OK, but "CocoaCalls" should be
> modified for Mach-O (conditional compiling).
> I attached modified "CocoaCalls".
>
> The distribution includes "WebKit-B" in "Cocoa Calls demo folder",
> which is a simple web browser a bit progressed from "webKitTest"
> in that it implements delegate methods from PowerMops.
> But by some reason it crashes on drawing a web page.
> I fixed and attached it on this mail (file "WebKit-B").
>
> That's all at present.
>
>
>
>
> Sincerely,
> Nao Sacrada
>
>
----------------------------------------------------------------
Mike Hore mik...@bi...
----------------------------------------------------------------
|
|
From: Mike H. <mik...@bi...> - 2005-12-20 22:36:27
|
Hi again Nao and others,
I hadn't realized that "Processes" was needed by AEClasses
which was needed by Nav. I've moved the file in the PPC source
folder so I shouldn't forget it again.
One other thing I thought of -- MachineException support is
included in CarbonEvents, but I found it prevented
me using gdb since it preempted gdb's catching of exceptions
which it relies on.
So at the moment, in zObjinit, I have the line
\ install_my_exception_handler
commented out. It could easily be reinstated but only if you
know you won't be using gdb.
Cheers, Mike.
>
> I downloaded PowerMops64-6 and tried to build 32-bit PowerMops
> (64bit?/MachO?= false/true, false/false).
> But it failed because of a missing source file "Processes".
> After adding the file, PowerMops could be built and run.
>
> PowerMops itself seems to be OK, but "CocoaCalls" should be
> modified for Mach-O (conditional compiling).
> I attached modified "CocoaCalls".
>
> The distribution includes "WebKit-B" in "Cocoa Calls demo folder",
> which is a simple web browser a bit progressed from "webKitTest"
> in that it implements delegate methods from PowerMops.
> But by some reason it crashes on drawing a web page.
> I fixed and attached it on this mail (file "WebKit-B").
>
> That's all at present.
>
>
>
>
> Sincerely,
> Nao Sacrada
>
>
----------------------------------------------------------------
Mike Hore mik...@bi...
----------------------------------------------------------------
|
|
From: Nao S. <sac...@yb...> - 2005-12-21 15:16:41
|
Hi Mike and All,
Mike Hore wrote:
> ...
> So at the moment, in zObjinit, I have the line
>
> \ install_my_exception_handler
>
> commented out. It could easily be reinstated but only if you
> know you won't be using gdb.
Exception handler seems not to work as it is.
Apple's documentation has been changed
(compare with a comment in file "CarbonEvents")
as
[quoted from a header file "MachineExceptions.h"]
/*
Note: An ExceptionHandler is NOT a UniversalProcPtr, except in
Carbon.
It must be a PowerPC function pointer with NO routine
descriptor,
except on Carbon, where it must be a UniversalProcPtr (TPP
actually)
to allow the interface to work from both CFM and Mach-O.
*/
[quoted from a header file "MachineExceptions.h" - end]
That is, exception handler is UniversalProcPtr in Carbon.
So in file "CarbonEvents", "install_my_exception_handler" should be
modified like following.
[code-begin]
syscall NewExceptionHandlerUPP
....
....
: install_my_exception_handler
['] myExceptionHandler 2+
[ macho? not ]
[IF]
__temp !
__temp
[THEN]
NewExceptionHandlerUPP
InstallExceptionHandler drop
;
[code-end]
After this change, exception handler seems to work.
(By the way, I hardly use gdb on PowerMops. ;-)
Sincerely,
Nao Sacrada
|
|
From: Mike H. <mik...@bi...> - 2005-12-22 09:14:23
|
Hi again Nao, > > After this change, exception handler seems to work. Thanks, I've put this in my copy now. > > (By the way, I hardly use gdb on PowerMops. ;-) That's fascinating. I've found I need to use it a lot. But I guess that's because of the very low level stuff I'm doing, and when I change something and nothing runs any more (which happens OFTEN!) I've got no other way to find what's going wrong. Cheers, Mike. > > Sincerely, > Nao Sacrada > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > PowerMops-BETA mailing list > Pow...@li... > https://lists.sourceforge.net/lists/listinfo/powermops-beta ---------------------------------------------------------------- Mike Hore mik...@bi... ---------------------------------------------------------------- |
|
From: Nao S. <sac...@yb...> - 2005-12-27 15:02:27
|
Hi Mike and All,
Two more problems.
(This is long again. Excuse me.)
I.
I got a crash of Mach-O PowerMops when I tried to save
PowerMopsFP (of course, FP means floating point) dictionary.
Unexpectedly what is crashing turned out to be the idle timer callback!
As the conclusion, the cause is the fact that word "(wm)" (stands for
Write Mach-o) rewrites data in info_block for new application.
Information in info_block is generally used only at "setup" time.
But the datum of the value of "rTOC" is used also in running for
callback words.
So when the code size to be saved in image spills over to new memory
page,
rTOC datum may be changed and callback word will crash because
pointer registers will be set based on wrong information.
I thought it might be an alternative to quit PowerMops every time after
saving dictionary.
But followings fixed the crash.
Commenting out a line that put rTOC datum in info_block,
in the definition of word "additional_info" in MachOMod.txt:
[code-begin]
: additional_info
\ info block in code area
\ datahead: data_sec_hdr info_block_addr OFFSET_TO_DATA_PTR + ! \
12/27/05 ns
instld?
IF \ offset from info_block_addr to TOC addr
....
[code-end]
Define new word "add_rTOC_info" before word "(wm)" as follows:
[code-begin]
: add_rTOC_info ( pos -- )
( pos ) info_block_addr + OFFSET_TO_DATA_PTR + code_start -
moveTo: ffcb drop \ set file pos to rTOC info field
datahead: data_sec_hdr PAD ! PAD 4 write: ffcb drop \ rewrite info
last: ffcb \ then restore file pos
;
[code-end]
Then modifying word "(wm)" as follows:
[code-begin]
: (wm) { RF_open? installing? \ svCL svDL -- }
[snipped]
\ ******* (real) __TEXT segment:
\ *** __text section
container_offs \ save current position \ 12/27/05 ns
code_start main_code_size write_to_container
( pos ) add_rTOC_info \ 12/27/05 ns
installing?
......
[code-end]
And one more.
(wm) closes created executable file at any time.
So in the definition of word "SaveDic" of Mach-O version
in file "zFEMod.txt", "close: ffcb drop" should be dropped.
[code-begin]
MachO?
[IF]
: SAVEDIC { \ fRefNum sv_use_paths? -- }
[snipped]
get: imageName 32 min myDocName place
false false (wm) \ false = dummy, false = not installing
\ fRefNum CloseResFile resChk
\ close: ffcb drop \ 12/27/05 ns
true -> saved? .saved
;
[code-end]
II.
Sliders on Preferences dialog sometimes crash on clicking.
This is because "click:" method of "RootCTL" class in
"PreferencesMod.txt"
uses a value "ThisPrefCtl" and a callback "ctlproc" at the same time.
Base address of clicked control is stored into "ThisPrefCtl" but
"ctlproc" defined in zCtl sends message to "ThisCtl".
However, as Mike said, control classes are already loaded in PowerMops
nucleus. So I tried to use classes in file "zCtl" also for control
classes
in "PreferencesMod.txt".
But then "Slider" didn't work.
As a conclusion, the cause that sliders don't work when it is based on
RootCtl class in "zCtl" is newly defined "enable:" and "disable:"
methods of RootCtl class.
They are :
[code-begin]
...
:m DISABLE:
false put: enabled?
get: alive? 0EXIT
get: rootCtlRef DeactivateControl drop
;m
:m ENABLE:
true put: enabled?
get: alive? 0EXIT
get: rootCtlRef ActivateControl drop
draw: self \ 17-mar-97 - sometimes we don't get drawn
\ unless we do this!
;m
...
[code-end]
They work in normal case. But they don't set:/clear: "enabled?"
flags of children views, which prevent sliders from updating the values.
For sliders on Preferences dialog are subviews of GroupBox that
is also a control view.
So by following changes, duplicated definitions of control classes
can be eliminated:
1. "ENABLE:" and "DISABLE:" methods of "RootCtl" class in "zCtl" should
be:
[code-begin]
:m DISABLE:
false put: enabled?
get: alive? 0EXIT
noclip \ needed in some case \ 12/27/05 ns
get: rootCtlRef DeactivateControl drop
\ then clear flags of children \ 12/27/05 ns
BEGIN each: children
WHILE clear: ivar> enabled? in class_as> View
REPEAT
;m
:m ENABLE:
true put: enabled?
get: alive? 0EXIT
get: rootCtlRef ActivateControl drop
draw: self \ 17-mar-97 - sometimes we don't get drawn
\ unless we do this!
\ then set flags of children \ 12/27/05 ns
BEGIN each: children
WHILE set: ivar> enabled? in class_as> View
REPEAT
;m
[code-end]
2. Comment out or delete the parts in PreferencesMod.txt
that have the comment, "**** Now in zCtl: ****".
3. "New:" method of Slider class defined in PreferencesMod.txt
should be:
[code-begin]
:m new:
setupnew: self
new: super
window: self windowref: class_as> window
addr: QDViewRect
get: initVal \ initial value
get: minVal \ minimum
get: maxval \ maximum
0 \ direction of pointing - up or left
get: numofticks \ num tick marks
1 \ true -- live tracking
['] CtlProc \ PrefCtlproc -> CtlProc \ 12/27/05 ns
addr: ctlHndl
CreateSliderControl drop
windupnew: self
;m
[code-end]
3. Comment out callback definition of "PrefCtlProc" in zFrontend.
[code-begin]
(* ********************
0 value ThisPrefCTL \ holds addr of control just clicked on
: PrefctlExec \ ( part# -- )
exec: [ thisPrefCtl ] ;
syscall NewControlActionUPP
syscall DisposeControlActionUPP
' NewControlActionUPP ' DisposeControlActionUPP
:callback PrefCtlProc { ^ctl part# -- } \ on PPC, callback parms must
be named
part# PrefctlExec
;callback
******************* *)
[code-end]
By the way, with these ENABLE: and DISABLE: methods,
Activate/Deactivate functions will be called on the root control
as many times as the number of controls on the window.
This fact doesn't seem to cause any harm. But it may be a bit
inefficient.
As an experimentation, I tried following:
Add "enable:" and "disable:" method definitions in class "TitledCtl"
defined in "zCtl"
[code-begin]
syscall IsControlActive
:CLASS TitledCtl super{ ROOTCTL }
....
:m enable:
get: alive? 0EXIT
get: CtlHndl IsControlActive ?EXIT
enable: super
;m
:m disable:
get: alive? 0EXIT
get: CtlHndl IsControlActive 0EXIT
disable: super
;m
;CLASS
[code-end]
And set superclass of "Slider" and "GroupBox" defined in
"PreferencesMod.txt" to be "TitledCtl".
And one more point.
In "draw:" method of class "RootCtl" defined in "zCtl",
it may be better to drop clipping before drawing
because it will draw all controls.
[code-begin]
:m DRAW:
\ (draw): super
0 0 SetOrigin
\ addr: QDviewRect ClipRect \ 12/27/05 ns
\ get: ctlHndl Draw1Control
\ noclip \ required in some situations. N.S.
get: rootCtlRef 16 1 SetUpControlBackground drop
get: rootCtlRef Draw1Control
noclip
;m
[code-end]
That's all.
Sincerely,
Nao Sacrada
|
|
From: Mike H. <mik...@bi...> - 2005-12-27 23:43:14
|
Hi Nao,
This is absolutely awesome!!
>
> Two more problems.
> (This is long again. Excuse me.)
>
> I.
> I got a crash of Mach-O PowerMops when I tried to save
> PowerMopsFP (of course, FP means floating point) dictionary.
>
> Unexpectedly what is crashing turned out to be the idle timer callback!
Now are you going to tell me you found this without gdb? :-)
When I ran into an idle timer callback crash a month or so ago it took
me a LONG time to find it!!
[details snipped]
> II.
> Sliders on Preferences dialog sometimes crash on clicking.
> This is because "click:" method of "RootCTL" class in
> "PreferencesMod.txt"
> uses a value "ThisPrefCtl" and a callback "ctlproc" at the same time.
> Base address of clicked control is stored into "ThisPrefCtl" but
> "ctlproc" defined in zCtl sends message to "ThisCtl".
I'd actually run into this one myself when I was testing a few weeks
ago, so I suspected something might need fixing in this area. Sorry
I didn't email you then -- I might have saved you some time. In the
end what I had seemed to be working so I forgot about it.
>
> However, as Mike said, control classes are already loaded in PowerMops
> nucleus. So I tried to use classes in file "zCtl" also for control
> classes
> in "PreferencesMod.txt".
> But then "Slider" didn't work.
Yes, this happened to me too, when I was making experimental changes
in this area. But I didn't have much time, so I didn't find a proper
fix. Now, of course, you've fixed it properlyt!
Cheers, Mike.
----------------------------------------------------------------
Mike Hore mik...@bi...
----------------------------------------------------------------
|
|
From: Nao S. <sac...@yb...> - 2005-12-28 04:18:48
|
Hi Mike,
Mike Hore wrote:
>>
>> Unexpectedly what is crashing turned out to be the idle timer
>> callback!
>
>
> Now are you going to tell me you found this without gdb? :-)
Well, no. I confess I used gdb. :-)
By the way, as you may have realized, the methods "enable:" and
"disable"
of TitledCtl class I wrote in previous mail were wrong.
I wrote:
> [code-begin]
> syscall IsControlActive
>
> :CLASS TitledCtl super{ ROOTCTL }
>
> ....
>
> :m enable:
> get: alive? 0EXIT
> get: CtlHndl IsControlActive ?EXIT
> enable: super
> ;m
> :m disable:
> get: alive? 0EXIT
> get: CtlHndl IsControlActive 0EXIT
> disable: super
> ;m
> ;CLASS
> [code-end]
>
These will block in some case setting "enabled?" flag I had suggested to
add in those of RootCtl class.
So don't incorporate these methods above in TitledCtl class.
Instead of the methods above, following modification
in RootCtl class may be better.
[code-begin]
:CLASS ROOTCTL super{ View }
....
....
:m DISABLE:
false put: enabled?
get: alive? 0EXIT
noclip \ needed in some case \ 12/27/05 ns
get: RootCtlRef IsControlActive \ 12/28/05 ns
IF
get: rootCtlRef DeactivateControl drop
THEN
\ then clear flags of children \ 12/27/05 ns
BEGIN each: children
WHILE clear: ivar> enabled? in class_as> View
REPEAT
;m
:m ENABLE:
true put: enabled?
get: alive? 0EXIT
get: RootCtlRef IsControlActive \ 12/28/05 ns
NIF
get: rootCtlRef ActivateControl drop
draw: self \ 17-mar-97 - sometimes we don't get drawn
\ unless we do this!
THEN
\ then set flags of children \ 12/27/05 ns
BEGIN each: children
WHILE set: ivar> enabled? in class_as> View
REPEAT
;m
[code-end]
Sincerely,
Nao Sacrada
|
|
From: Nao S. <sac...@yb...> - 2005-12-21 13:57:45
Attachments:
info.plist.tmpl
mops.rsrc
|
Hi Mike and All,
I. There are some problems around "install" feature in
PowerMops64-6.
1. Word "(exp)" contains a bug.
"(exp)" is defined in files "zPEF" and "MachOMod.txt" and
it gets pointers of exported words (defined with :entry) on
creating a shared library.
But FP flag check in (exp) is not working, so that,
when an exported word has FP parameters, the shared library crashes
on linking.
"(exp)" in MachOMod.txt should be modified like
[code-begin]
: (exp) { theCfa dummy \ addr -- }
[sniped]
theCfa dup
1- c@ 1 and \ $ 10 and \ fp flags? \ 12/21/05 ns
IF 6 + ELSE 2+ THEN \ get addr of first instruction of defn
code_start - $ 1000 + DEF_OF_OFFSET +
>value: mynlist
.....
[code-end]
and "(exp)" in zPEF should be modified like
[code-begin]
: (exp) { theCfa dummy \ addr -- }
[sniped]
theCfa dup
1- c@ 1 and \ $ 10 and \ fp flags? \ 12/21/05 ns
IF 6 + ELSE 2+ THEN \ get addr of first instruction of defn
code_start - , 0 ,
....
[code-end]
After these modifications, a weird manipulation "2 ->
fpr_nonparm_entry_cnt"
that I added in word ";entry" defined in "sharedlibMod.txt", becomes
meaningless.
[modified code-begin]
: ;ENTRY
307 ?defn
\ 2 -> fpr_nonparm_entry_cnt \ 12/21/05 ns
300 postpone ;
4 --> CDP \ delete the blr
['] entry_windup_code 2+ CDP entry_windup_code_size aligned_move
...
[modified code-end]
2. MachO PowerMops crashes on "install".
It is because a file "info.plist.tmpl" is missed in "MacOS" folder.
The file is a template to create info.plist file for installed
application.
I attached a corrected version of "info.plist.tmpl" file.
Please put it in "MachOS" folder, though it is not necessary for PEF
PowerMops.
|
|
From: Mike H. <mik...@bi...> - 2005-12-22 09:14:18
|
Hi Nao,
That's INCREDIBLE!! How did you find and fix all those things
so quickly!
Many thanks, as always!
-- Mike.
>
>
> I. There are some problems around "install" feature in
> PowerMops64-6.
>
> 1. Word "(exp)" contains a bug.
> "(exp)" is defined in files "zPEF" and "MachOMod.txt" and
> it gets pointers of exported words (defined with :entry) on
> creating a shared library.
> But FP flag check in (exp) is not working, so that,
> when an exported word has FP parameters, the shared library crashes
> on linking.
>
> "(exp)" in MachOMod.txt should be modified like
>
> [code-begin]
>
> : (exp) { theCfa dummy \ addr -- }
>
> [sniped]
>
> theCfa dup
> 1- c@ 1 and \ $ 10 and \ fp flags? \ 12/21/05 ns
> IF 6 + ELSE 2+ THEN \ get addr of first instruction of defn
> code_start - $ 1000 + DEF_OF_OFFSET +
>
>> value: mynlist
>
> .....
>
> [code-end]
>
> and "(exp)" in zPEF should be modified like
>
> [code-begin]
>
> : (exp) { theCfa dummy \ addr -- }
>
> [sniped]
>
> theCfa dup
> 1- c@ 1 and \ $ 10 and \ fp flags? \ 12/21/05 ns
> IF 6 + ELSE 2+ THEN \ get addr of first instruction of defn
> code_start - , 0 ,
> ....
>
> [code-end]
>
> After these modifications, a weird manipulation "2 ->
> fpr_nonparm_entry_cnt"
> that I added in word ";entry" defined in "sharedlibMod.txt", becomes
> meaningless.
>
> [modified code-begin]
> : ;ENTRY
> 307 ?defn
> \ 2 -> fpr_nonparm_entry_cnt \ 12/21/05 ns
> 300 postpone ;
> 4 --> CDP \ delete the blr
>
> ['] entry_windup_code 2+ CDP entry_windup_code_size aligned_move
> ...
>
> [modified code-end]
>
>
> 2. MachO PowerMops crashes on "install".
> It is because a file "info.plist.tmpl" is missed in "MacOS" folder.
> The file is a template to create info.plist file for installed
> application.
> I attached a corrected version of "info.plist.tmpl" file.
> Please put it in "MachOS" folder, though it is not necessary for PEF
> PowerMops.
>
>
>
> 3. DITL resource for iDLG (Install dialog) was changed.
> In installing MachO framework one more dialog item (a static text)
> is necessary. I attached modified "mops.rsrc".
>
>
>
> Then word "INSTALLWIND" defined at the last of file "zInstlmod.txt"
> should be modified like
>
> [code-begin]
> : INSTALLWIND
> openMR
> getnew: iDlg getR
> 21 hideItem: iDlg \ PowerMops doesn't use this one
> 24 hideItem: iDlg \ unused on PEF \ 12/21/05 ns
> " go" 10 putText: iDlg
> .....
>
> [code-end]
>
> to hide the text item on PEF PowerMops.
>
>
> With these, Install feature seems to work.
>
>
> II. A preferences problem on Mac OS 9.2.2. (32bit/PEF PowerMops)
>
> 1. "Find" button and Drag&Drop on "HFS Paths Dialog"
> don't work on OS 9 because they use "FrWkCall"
>
> In file "PreferencesMod.txt", "CFStringGetCharacters()"
> should be conditionally declared like following:
>
> [code-begin]
>
> \ trick for a struct parameter
> macho?
> [IF]
> framework Carbon.framework
> frwkcall CFStringGetCharacters { stringref loc size ^buff -- }
> [ELSE]
> library CarbonLib
> libcall CFStringGetCharacters { stringref loc size ^buff -- }
> [THEN]
>
> [code-end]
>
> 2. Preferences dialog won't open on OS 9.
> As a conclusion, a use-QD flag bit for Tiger seems
> to be the cause of the problem.
>
> In word "SetPrefs" defined in file "PreferencesMod.txt",
>
> [code-begin]
>
> : SetPrefs
>
> [snipped]
>
> InitCursor
> WRect " Preferences"
> konst kWindowCloseBoxAttribute
> OSX?
> IF
> $ 40000000 OR \ use QD on Tiger
> THEN
> false false PrefView new: myPrefs
> ....
>
> [code-end]
>
> seems to fix the problem on OS9.
>
>
> Sincerely,
> Nao Sacrada
>
>
----------------------------------------------------------------
Mike Hore mik...@bi...
----------------------------------------------------------------
|
|
From: Nao S. <sac...@yb...> - 2005-12-23 15:05:59
|
Hi Mike and All,
I have some question and recommendations on PowerMops64-6.
Excuse me for the lengthy mail.
1. MLTEView's behavior has been changed a little.
MLTEView will be no longer automatically focused/unfocused
according to enabling/disabling of its window.
So the window which contains MLTEView, should explicitly send
"true/false focus:" to the MLTEView, if necessary.
Anyway, it may be better to describe it in documentation, I think.
2. New click event handling.
New window click event handling works generally.
The handler sets "__clicked_wind" and quit event loop
with reason 6, then our main EventLoop send "content:"
message to the clicked window. (see file "CarbonEvents").
But it may break click handling on modal window (of non-dialog class).
Because in modal window, event handling will be processed
entirely in modal event loop (via a function
"RunAppModalLoopForWindow()" )
so that we can't catch the click event in our main EventLoop.
In fact, buttons on custom modal dialogs of my application
became insensible to click.
I guess special click event handler callback for modal window
or some modal window event loop word may be necessary.
I think it may also be better to be referred to in document.
3. File "demo.rsrc" for grDemo is missed in the distribution.
By the way, I think it better to include 2 copies of "demo.rsrc",
one in "MacOS" folder and another in "demo folder".
When grdemo is run on PowerMops, the resource in "MacOS" folder
will be used. And when someone try to install it as a stand-alone app,
that in "demo folder" could be used.
Then if word "go" in file "grdemo" is modified like
[code-begin]
: GO
['] bye -> byeVec \ for safety when installed on OSX \ 12/23/05
ns instld? Macho? not and \ 12/23/05 ns
NIF
0 ( mopsRsrcDirID ) 0 " demo.rsrc" str255 0 HOpenResFile drop
THEN
" Curves" new: dWind
getnew: appleMen getnew: grafMen
......
[code-end]
installing grDemo on Mach-O PowerMops will be easier.
Then, installing of grDemo on PEF PowerMops will be
the same as before.
When installing it on Mach-O PowerMops, after building the executable
putting a copy of "demo.rsrc" into "MacOS" folder of installed app,
then packaging by adding .app extension will complete Mach-O grDemo.
By the way, "mopsRsrcDirID" means the directory where PowerMops
executable
exists (absolute path). So when an application made with Mach-O
PowerMops uses resource fork resource, the ID should be 0,
which means the same folder as that the executable of the application
is in even when it is installed as a standalone.
To Mike: File "seecode" in demo folder can be safely excluded from
distribution. -- I think it is a garbage I forgot to delete.
4. A detour of Panther's bug.
There is a bug around "TXNCut()" and "TXNCopy()" of MLTE
on Panther, which sometimes causes troubles
(for me, "Find" dialog of QE crashes with error alert).
This bug has been fixed on Tiger, I heard.
I would like to recommend to put a detour for Panther. That is,
In file MLTEView, declare 3 syscalls :
[code-begin]
syscall PutScrapFlavor
syscall ClearCurrentScrap
syscall GetCurrentScrap
[code-end]
Then modify around methods "Copy:" and "Cut:" of MLTEView class like
following :
[code-begin]
...
:m copy:
TEMP{ String TmpString }
getselect: self = ?EXIT
TmpString setStringFromSelection: self
ClearCurrentScrap drop
pad GetCurrentScrap drop
pad @ 'type TEXT 0 all: TMPString swap
PutScrapFlavor drop \ detour of bug \ 08/04/05 ns
\ get: TXNobject TXNCopy drop \ drop the OSStatus returned
;m
:m clear: get: TXNobject TXNClear drop ;m
:m cut:
TEMP{ String TmpString }
getselect: self = ?EXIT
TmpString setStringFromSelection: self
clear: self
ClearCurrentScrap drop
pad GetCurrentScrap drop
pad @ 'type TEXT 0 all: TMPString swap
PutScrapFlavor drop \ detour of bug \ 08/04/05 ns
\ get: TXNobject TXNCut drop
;m
\ :m clear: get: TXNobject TXNClear drop ;m \ moved \ 08/04/05 ns
:m paste: get: TXNobject TXNPaste drop ;m
....
[code-end]
5. Search paths for framework call
At present, there is a discrepancy in framework search paths
between MachO and PEF.
PEF PowerMops will not search the executable folder.
But after an insertion of
[code-begin]
macho? not
[IF]
syscall FSpMakeFSRef
[THEN]
[code-end]
in file "sharedlibs",
"GetLibraryRef" (defined in "sharedlibs") in MachO version
seems to work also for PEF PowerMops.
Is there any reason for this difference?
That's all.
Sincerely,
Nao Sacrada
|
|
From: Mike H. <mik...@bi...> - 2005-12-24 02:34:10
|
Hi Nao,
I won't answer everything straight away since though it's
the weekend it's Christmas Eve which means there are various
things going on that I have to be involved in...
>
> I have some question and recommendations on PowerMops64-6.
> Excuse me for the lengthy mail.
>
> 1. MLTEView's behavior has been changed a little.
> MLTEView will be no longer automatically focused/unfocused
> according to enabling/disabling of its window.
> So the window which contains MLTEView, should explicitly send
> "true/false focus:" to the MLTEView, if necessary.
> Anyway, it may be better to describe it in documentation, I think.
I'm really sorry -- for my work I needed windows with multiple
MLTEviews, and I was in a hurry, so I made quite a few changes
and forgot to tell you all about them!!! Also some changes
to View.
The app is now working well, but MLTEview probably needs
a bit of cleaning up. I was in a hurry. The focussing
change was so that when some other view in the window
gets clicked, the MLTEview automatically unfocusses
itself. Without these changes, I would have had to do
something like what your multi-MLTE code did, and keep
a list of MLTEviews. I was trying to make it simpler.
The significant change in View is that view_for_click?:
now checks ALL its child views instead of stopping when
one returns true. This way a view can take some action
it it gets a view_for_click?: and it's going to return
false. With the new arrangement, it always gets called.
MLTEview now relies on this to unfocus if it's not the
view that was clicked. This way we don't need any
linked lists of views.
>
> 2. New click event handling.
> New window click event handling works generally.
> The handler sets "__clicked_wind" and quit event loop
> with reason 6, then our main EventLoop send "content:"
> message to the clicked window. (see file "CarbonEvents").
The idea here, as I'm sure you all realize, is that a lot of
code might get executed as the result of a content click, and
it's best to not do this in the middle of a callback.
>
> But it may break click handling on modal window (of non-dialog class).
> Because in modal window, event handling will be processed
> entirely in modal event loop (via a function
> "RunAppModalLoopForWindow()" )
> so that we can't catch the click event in our main EventLoop.
> In fact, buttons on custom modal dialogs of my application
> became insensible to click.
>
> I guess special click event handler callback for modal window
> or some modal window event loop word may be necessary.
> I think it may also be better to be referred to in document.
I'll put this on my to-do list. (This is a LINO list --
last-in, never out -- just kidding, I hope... :-)
>
> 3. File "demo.rsrc" for grDemo is missed in the distribution.
> By the way, I think it better to include 2 copies of "demo.rsrc",
> one in "MacOS" folder and another in "demo folder".
> When grdemo is run on PowerMops, the resource in "MacOS" folder
> will be used. And when someone try to install it as a stand-alone app,
> that in "demo folder" could be used.
>
> Then if word "go" in file "grdemo" is modified like
>
> [code-begin]
> : GO
> ['] bye -> byeVec \ for safety when installed on OSX \ 12/23/05
> ns instld? Macho? not and \ 12/23/05 ns
> NIF
> 0 ( mopsRsrcDirID ) 0 " demo.rsrc" str255 0 HOpenResFile drop
> THEN
> " Curves" new: dWind
> getnew: appleMen getnew: grafMen
> ......
>
> [code-end]
>
> installing grDemo on Mach-O PowerMops will be easier.
>
> Then, installing of grDemo on PEF PowerMops will be
> the same as before.
> When installing it on Mach-O PowerMops, after building the executable
> putting a copy of "demo.rsrc" into "MacOS" folder of installed app,
> then packaging by adding .app extension will complete Mach-O grDemo.
>
Thanks, good suggestion.
> By the way, "mopsRsrcDirID" means the directory where PowerMops
> executable
> exists (absolute path). So when an application made with Mach-O
> PowerMops uses resource fork resource, the ID should be 0,
> which means the same folder as that the executable of the application
> is in even when it is installed as a standalone.
>
> To Mike: File "seecode" in demo folder can be safely excluded from
> distribution. -- I think it is a garbage I forgot to delete.
OK.
>
> 4. A detour of Panther's bug.
> There is a bug around "TXNCut()" and "TXNCopy()" of MLTE
> on Panther, which sometimes causes troubles
> (for me, "Find" dialog of QE crashes with error alert).
> This bug has been fixed on Tiger, I heard.
I've been doing cuts and copies in MLTE windows on Tiger, so
I guess it's working OK.
>
> I would like to recommend to put a detour for Panther. That is,
>
> In file MLTEView, declare 3 syscalls :
>
> [code-begin]
>
> syscall PutScrapFlavor
> syscall ClearCurrentScrap
> syscall GetCurrentScrap
>
> [code-end]
>
> Then modify around methods "Copy:" and "Cut:" of MLTEView class like
> following :
>
> [code-begin]
>
> ...
> :m copy:
> TEMP{ String TmpString }
> getselect: self = ?EXIT
> TmpString setStringFromSelection: self
> ClearCurrentScrap drop
> pad GetCurrentScrap drop
> pad @ 'type TEXT 0 all: TMPString swap
> PutScrapFlavor drop \ detour of bug \ 08/04/05 ns
> \ get: TXNobject TXNCopy drop \ drop the OSStatus returned
> ;m
> :m clear: get: TXNobject TXNClear drop ;m
> :m cut:
> TEMP{ String TmpString }
> getselect: self = ?EXIT
> TmpString setStringFromSelection: self
> clear: self
> ClearCurrentScrap drop
> pad GetCurrentScrap drop
> pad @ 'type TEXT 0 all: TMPString swap
> PutScrapFlavor drop \ detour of bug \ 08/04/05 ns
> \ get: TXNobject TXNCut drop
> ;m
> \ :m clear: get: TXNobject TXNClear drop ;m \ moved \ 08/04/05 ns
> :m paste: get: TXNobject TXNPaste drop ;m
>
> ....
> [code-end]
>
Thanks.
>
> 5. Search paths for framework call
>
> At present, there is a discrepancy in framework search paths
> between MachO and PEF.
> PEF PowerMops will not search the executable folder.
>
> But after an insertion of
>
> [code-begin]
>
> macho? not
> [IF]
> syscall FSpMakeFSRef
> [THEN]
>
> [code-end]
>
> in file "sharedlibs",
> "GetLibraryRef" (defined in "sharedlibs") in MachO version
> seems to work also for PEF PowerMops.
> Is there any reason for this difference?
I don't think so. It was probably just accidental.
Cheers, Mike.
----------------------------------------------------------------
Mike Hore mik...@bi...
----------------------------------------------------------------
|
|
From: George T. <gwt...@ca...> - 2005-12-24 15:05:00
|
Nao,
Re new click event handling.
I gather the new approach eliminates the previous reliance on the carbon
standard event handler. In other words, a click doesn't automatically
activate the window -- the app can then decide what to do with the click.
If so, this would be a much appreciated change that would bring OSX closer
to the 68k approach.
Are you planning to retrofit this to the 32 bit version so I can run it
on my G3?
George
On 12/23/05 10:05 AM, "Nao Sacrada" <sac...@yb...> wrote:
> Hi Mike and All,
>
> I have some question and recommendations on PowerMops64-6.
> Excuse me for the lengthy mail.
>
> 1. MLTEView's behavior has been changed a little.
> MLTEView will be no longer automatically focused/unfocused
> according to enabling/disabling of its window.
> So the window which contains MLTEView, should explicitly send
> "true/false focus:" to the MLTEView, if necessary.
> Anyway, it may be better to describe it in documentation, I think.
>
> 2. New click event handling.
> New window click event handling works generally.
> The handler sets "__clicked_wind" and quit event loop
> with reason 6, then our main EventLoop send "content:"
> message to the clicked window. (see file "CarbonEvents").
>
> But it may break click handling on modal window (of non-dialog class).
> Because in modal window, event handling will be processed
> entirely in modal event loop (via a function
> "RunAppModalLoopForWindow()" )
> so that we can't catch the click event in our main EventLoop.
> In fact, buttons on custom modal dialogs of my application
> became insensible to click.
>
> I guess special click event handler callback for modal window
> or some modal window event loop word may be necessary.
> I think it may also be better to be referred to in document.
>
> 3. File "demo.rsrc" for grDemo is missed in the distribution.
> By the way, I think it better to include 2 copies of "demo.rsrc",
> one in "MacOS" folder and another in "demo folder".
> When grdemo is run on PowerMops, the resource in "MacOS" folder
> will be used. And when someone try to install it as a stand-alone app,
> that in "demo folder" could be used.
>
> Then if word "go" in file "grdemo" is modified like
>
> [code-begin]
> : GO
> ['] bye -> byeVec \ for safety when installed on OSX \ 12/23/05
> ns instld? Macho? not and \ 12/23/05 ns
> NIF
> 0 ( mopsRsrcDirID ) 0 " demo.rsrc" str255 0 HOpenResFile drop
> THEN
> " Curves" new: dWind
> getnew: appleMen getnew: grafMen
> ......
>
> [code-end]
>
> installing grDemo on Mach-O PowerMops will be easier.
>
> Then, installing of grDemo on PEF PowerMops will be
> the same as before.
> When installing it on Mach-O PowerMops, after building the executable
> putting a copy of "demo.rsrc" into "MacOS" folder of installed app,
> then packaging by adding .app extension will complete Mach-O grDemo.
>
> By the way, "mopsRsrcDirID" means the directory where PowerMops
> executable
> exists (absolute path). So when an application made with Mach-O
> PowerMops uses resource fork resource, the ID should be 0,
> which means the same folder as that the executable of the application
> is in even when it is installed as a standalone.
>
> To Mike: File "seecode" in demo folder can be safely excluded from
> distribution. -- I think it is a garbage I forgot to delete.
>
> 4. A detour of Panther's bug.
> There is a bug around "TXNCut()" and "TXNCopy()" of MLTE
> on Panther, which sometimes causes troubles
> (for me, "Find" dialog of QE crashes with error alert).
> This bug has been fixed on Tiger, I heard.
>
> I would like to recommend to put a detour for Panther. That is,
>
> In file MLTEView, declare 3 syscalls :
>
> [code-begin]
>
> syscall PutScrapFlavor
> syscall ClearCurrentScrap
> syscall GetCurrentScrap
>
> [code-end]
>
> Then modify around methods "Copy:" and "Cut:" of MLTEView class like
> following :
>
> [code-begin]
>
> ...
> :m copy:
> TEMP{ String TmpString }
> getselect: self = ?EXIT
> TmpString setStringFromSelection: self
> ClearCurrentScrap drop
> pad GetCurrentScrap drop
> pad @ 'type TEXT 0 all: TMPString swap
> PutScrapFlavor drop \ detour of bug \ 08/04/05 ns
> \ get: TXNobject TXNCopy drop \ drop the OSStatus returned
> ;m
> :m clear: get: TXNobject TXNClear drop ;m
> :m cut:
> TEMP{ String TmpString }
> getselect: self = ?EXIT
> TmpString setStringFromSelection: self
> clear: self
> ClearCurrentScrap drop
> pad GetCurrentScrap drop
> pad @ 'type TEXT 0 all: TMPString swap
> PutScrapFlavor drop \ detour of bug \ 08/04/05 ns
> \ get: TXNobject TXNCut drop
> ;m
> \ :m clear: get: TXNobject TXNClear drop ;m \ moved \ 08/04/05 ns
> :m paste: get: TXNobject TXNPaste drop ;m
>
> ....
> [code-end]
>
>
> 5. Search paths for framework call
>
> At present, there is a discrepancy in framework search paths
> between MachO and PEF.
> PEF PowerMops will not search the executable folder.
>
> But after an insertion of
>
> [code-begin]
>
> macho? not
> [IF]
> syscall FSpMakeFSRef
> [THEN]
>
> [code-end]
>
> in file "sharedlibs",
> "GetLibraryRef" (defined in "sharedlibs") in MachO version
> seems to work also for PEF PowerMops.
> Is there any reason for this difference?
>
>
> That's all.
>
> Sincerely,
> Nao Sacrada
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> PowerMops-BETA mailing list
> Pow...@li...
> https://lists.sourceforge.net/lists/listinfo/powermops-beta
--
Regards,
George Turner
Ottawa, Canada
(613) 226-5029
|
|
From: Nao S. <sac...@yb...> - 2005-12-25 07:55:22
|
Hi George, George Turner wrote: > > Nao, > Re new click event handling. > I gather the new approach eliminates the previous reliance on the > carbon > standard event handler. In other words, a click doesn't automatically > activate the window -- the app can then decide what to do with the > click. Well, I think, the fact is that the scheme of click event handling is changed, but in normal case there will be not much difference from before. Previously (though still "currently") click event was processed via "content:" method of window[+] class, and the "content:" message was sent from within callback word, say, "doWindowClick" defined in "CarbonEvents". In new scheme "content:" method still do the main task of event handling, but the message is sent not from within the callback word but from our EventLoop. So when you are using custom eventloop, "content:" message may not be sent in some case. > If so, this would be a much appreciated change that would bring OSX > closer > to the 68k approach. I agree that our new click event handling is close to classic event handling (if my observation is correct). The main work is done in EventLoop via case switch. So by customizing eventloop we can manipulate click event handling flow. As Mike pointed out, when "content:" method must do many things, it is safer to send the message from eventloop. However, we can still install customized event handler callback in each window object, which may probably be Carbon approach. It is generally better to have more alternatives, I think. > Are you planning to retrofit this to the 32 bit version so I can > run it > on my G3? > PowerMops64-6 can be built as 32bit PowerMops (after addition of "Processes" file that is accidentally missed from the distribution.) Since 64bit and 32bit PowerMops are on the same code base, I think you already can get the same result on your G3 by rebuilding PMops and PowerMops with "64bit?" constant flag being false. I guess the new approach to click event handling will be the new standard also for 32bit PowerMops. Sincerely, Nao Sacrada |
|
From: Doug H. <dho...@ta...> - 2005-12-26 11:07:17
|
Hi All,
Sorry I've been out of touch awhile. Work has taken up most of my free
time. But things are looking better now.
Nao wrote:
> 4. A detour of Panther's bug.
> There is a bug around "TXNCut()" and "TXNCopy()" of MLTE
> on Panther, which sometimes causes troubles
> (for me, "Find" dialog of QE crashes with error alert).
> This bug has been fixed on Tiger, I heard.
Nao, Are the problems with QE solved with your recommended Panther
detour below? As you may know, I am using classic TextEdit for the QE
"Find" dialog.
Regards,
-Doug
>
> I would like to recommend to put a detour for Panther. That is,
>
> In file MLTEView, declare 3 syscalls :
>
> [code-begin]
>
> syscall PutScrapFlavor
> syscall ClearCurrentScrap
> syscall GetCurrentScrap
>
> [code-end]
>
> Then modify around methods "Copy:" and "Cut:" of MLTEView class like
> following :
>
> [code-begin]
>
> ...
> :m copy:
> TEMP{ String TmpString }
> getselect: self = ?EXIT
> TmpString setStringFromSelection: self
> ClearCurrentScrap drop
> pad GetCurrentScrap drop
> pad @ 'type TEXT 0 all: TMPString swap
> PutScrapFlavor drop \ detour of bug \ 08/04/05 ns
> \ get: TXNobject TXNCopy drop \ drop the OSStatus returned
> ;m
> :m clear: get: TXNobject TXNClear drop ;m
> :m cut:
> TEMP{ String TmpString }
> getselect: self = ?EXIT
> TmpString setStringFromSelection: self
> clear: self
> ClearCurrentScrap drop
> pad GetCurrentScrap drop
> pad @ 'type TEXT 0 all: TMPString swap
> PutScrapFlavor drop \ detour of bug \ 08/04/05 ns
> \ get: TXNobject TXNCut drop
> ;m
> \ :m clear: get: TXNobject TXNClear drop ;m \ moved \ 08/04/05 ns
> :m paste: get: TXNobject TXNPaste drop ;m
>
> ....
> [code-end]
|
|
From: Nao S. <sac...@yb...> - 2005-12-26 16:09:42
|
Hi Doug and All, Doug Hoffman wrote: > > Nao wrote: > >> 4. A detour of Panther's bug. >> There is a bug around "TXNCut()" and "TXNCopy()" of MLTE >> on Panther, which sometimes causes troubles >> (for me, "Find" dialog of QE crashes with error alert). >> This bug has been fixed on Tiger, I heard. > > Nao, Are the problems with QE solved with your recommended Panther > detour below? I think so. But unfortunately it has turned out that the behavior of "TXNCut()" or "TXNCopy()" is not quite the same as that of my supposed fix using "PutScrapFlavor()". However I just have found a simpler and better solution! That is: 1. Keep "cut:" or "copy:" method of MLTEView class same as before (that is, use "TXNCopy/Cut()"). 2. Then call a function "CallInScrapPromises()" in word "bye+" defined in file "MLTEFwindMod.txt". The result is like following: In file "MLTEFwindMod.txt" [code-begin] syscall CallInScrapPromises : BYE+ CallInScrapPromises drop saveWorksheet bye ; [code-end] That's all. From experiments, QE problem seems to be solved for me. I now think that could not be called a bug, but rather unexpected specification of Panther. To make sure, I will write here how to reproduce the QE problem. 1. Launch PowerMops and QuickEdit. 2. Type some characters on PowerMops console and copy or cut it. 3. Quit PowerMops. 4. Try to display "find" dialog of QuickEdit. Then alert dialog will be displayed and QE fall into, say, an alert loop. Then you can force to quit QE. Or click on OK button of the alert box, then press command+Q immediately after it. Sincerely, Nao Sacrada |
|
From: Nao S. <sac...@yb...> - 2005-12-26 23:55:52
|
Hi All, A correction: I wrote: > 1. > Keep "cut:" or "copy:" method of MLTEView class same as before > (that is, use "TXNCopy/Cut()"). > > 2. > Then call a function "CallInScrapPromises()" in word "bye+" defined in > file "MLTEFwindMod.txt". The result is like following: > > In file "MLTEFwindMod.txt" > [code-begin] > > syscall CallInScrapPromises > > : BYE+ CallInScrapPromises drop saveWorksheet bye ; > > [code-end] > But for the sake of an application to be installed, CallInScrapPromises() may be better to be inserted in "copy:" and "Cut:" method of MLTEView class, not in "BYE+". That is: In MLTEView class [code-begin] .... :m copy: get: TXNobject TXNCopy drop \ drop the OSStatus returned CallInScrapPromises drop ;m :m cut: get: TXNobject TXNCut drop CallInScrapPromises drop ;m ... [code-end] "syscall CallInScrapPromises" is also necessary at somewhere, of course. Sincerely, Nao Sacrada |
|
From: Doug H. <dho...@ta...> - 2005-12-27 13:16:32
|
Nao wrote: > From experiments, QE problem seems to be solved for me. > I now think that could not be called a bug, > but rather unexpected specification of Panther. > > To make sure, I will write here how to reproduce the QE problem. > > 1. Launch PowerMops and QuickEdit. > 2. Type some characters on PowerMops console and copy or cut it. > 3. Quit PowerMops. > 4. Try to display "find" dialog of QuickEdit. > > Then alert dialog will be displayed and QE fall into, say, an alert > loop. > Then you can force to quit QE. Or click on OK button of the alert box, > then press command+Q immediately after it. Yes. I get exactly the same problem when I do the above. For reasons I can't explain, on the latest (unreleased to anyone) version of QE there is no error dialog loop. But there is nothing on the clipboard when a paste is attempted. Just to be sure this isn't a problem with QE, I tried the same with ResEdit and got the same results: that is, no error loop but nothing on the clipboard when there should be some text pasted. So I guess pursuing a "fix" for PowerMops is indeed the correct thing to do. Regards, -Doug |
|
From: Mike H. <mik...@bi...> - 2005-12-27 23:49:56
|
Hi Doug and Nao, Just in case you don't know already, this bug doesn't show up in Tiger. Everything works like it should. -- Mike. > Nao wrote: > >> From experiments, QE problem seems to be solved for me. >> I now think that could not be called a bug, >> but rather unexpected specification of Panther. >> >> To make sure, I will write here how to reproduce the QE problem. >> >> 1. Launch PowerMops and QuickEdit. >> 2. Type some characters on PowerMops console and copy or cut it. >> 3. Quit PowerMops. >> 4. Try to display "find" dialog of QuickEdit. >> >> Then alert dialog will be displayed and QE fall into, say, an alert >> loop. >> Then you can force to quit QE. Or click on OK button of the alert box, >> then press command+Q immediately after it. > > Yes. I get exactly the same problem when I do the above. > > For reasons I can't explain, on the latest (unreleased to anyone) > version of QE there is no error dialog loop. But there is nothing on > the clipboard when a paste is attempted. Just to be sure this isn't a > problem with QE, I tried the same with ResEdit and got the same > results: that is, no error loop but nothing on the clipboard when > there should be some text pasted. > > So I guess pursuing a "fix" for PowerMops is indeed the correct thing > to do. > > Regards, > > -Doug > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > PowerMops-BETA mailing list > Pow...@li... > https://lists.sourceforge.net/lists/listinfo/powermops-beta ---------------------------------------------------------------- Mike Hore mik...@bi... ---------------------------------------------------------------- |
|
From: Doug H. <dho...@ta...> - 2005-12-28 11:35:39
|
Hi Mike, > Just in case you don't know already, this bug doesn't show > up in Tiger. Everything works like it should. Great! Thanks for that. I've a slightly newer version of QE that is just a rebuild based on the latest Carbon MacForth. I'll try to get it out soon. Ward has made things a bit more robust and added a few things such as improved horizontal scrolling and the display of non-breaking spaces. The non-breaking space display was at my request because they can cause a lot of problems if you don't realize they are there. Guess how I know ;-) Regards, -Doug |
|
From: George T. <gwt...@ca...> - 2005-12-28 14:31:54
|
Doug,
Thanks for that -- getting rid of non-printing characters will be a big
help. Presumably there are no others.
George
On 12/28/05 6:35 AM, "Doug Hoffman" <dho...@ta...> wrote:
> Hi Mike,
>
>> Just in case you don't know already, this bug doesn't show
>> up in Tiger. Everything works like it should.
>
> Great! Thanks for that. I've a slightly newer version of QE that is
> just a rebuild based on the latest Carbon MacForth. I'll try to get it
> out soon. Ward has made things a bit more robust and added a few
> things such as improved horizontal scrolling and the display of
> non-breaking spaces. The non-breaking space display was at my request
> because they can cause a lot of problems if you don't realize they are
> there. Guess how I know ;-)
>
> Regards,
>
> -Doug
|
|
From: Nao S. <sac...@yb...> - 2006-01-05 16:37:31
|
Happy New Year! Then. I found word "depth" returns wrong number on 32-Bit PowerMops. I believe it happens only on 32-bit PowerMops, not on 64-bit one. For example: type [code-begin] 1 2 3<enter> [code-end] then, if you execute "depth" it returns 4. But it should return 3. Present definition of "depth" in file "pnuc1" is: [code-begin] : DEPTH SP0 clearHi32 SP - 3 a>> ; [code-end] The definition in PowerMops64-5 or before was: [code-begin] : DEPTH SP0 SP - 3 a>> ( 2+ ) ; [code-end] But previous versions don't have the same problem. However, I think previous definition would have already been wrong without optimization. For it is forgetting to discount an item "SP0" which is pushed onto stack before getting "SP". But by optimization of compiler "SP0" is not really pushed onto stack memory but the calculation is done only on registers, so that the problem has never come to the front. But a call of new word "clearHi32", though the content of the word is "null" on 32-bit mode, causes real push of "SP0" on stack. Since in the case of 64-bit build "clearHi32" is one inlined machine instruction, I infer "depth" will return the correct value. My trial of fix is as follows: [code-begin] : DEPTH SP negate \ 01/05/06 ns SP0 clearHi32 + ( SP - ) 3 a>> ; \ 01/05/06 ns [code-end] It works on 32-bit PowerMops. I guess it will work also on 64 bit PowerMops. But then stack display word ".s+" defined in MLTEFwindMod.txt should be adjusted to this modification. After some experiments, it turned out that following would fix it. The definition of "sDepth" in MLTEFwindMod.txt: [code-begin] : sDepth ( -- depth ) \ 02/12/05 dbh depth ( actw ^TW <> IF 1+ THEN ) 1+ ; \ 01/06/06 ns [code-end] But this surely breaks something on 64-bit PowerMops. (I expect, though, it may not break Doug's fix.) Since I have no 64-Bit PPC, that's all what I could do. Excuse me. Sincerely, Nao Sacrada |
|
From: Mike H. <mik...@bi...> - 2006-01-05 23:12:33
|
> Happy New Year! And to you too!! I remember I had to make a few changes around DEPTH when I was doing the 64-bit changes -- it also involved the stack display and the stack underflow check. So it looks like this lingering bug was the result. Thanks for the fix -- I'll check it out with a 64-bit build when I get time. Cheers, Mike. >=20 > Then. > I found word "depth" returns wrong number on 32-Bit > PowerMops. I believe it happens only on 32-bit PowerMops, > not on 64-bit one. >=20 > For example: > type > [code-begin] >=20 > 1 2 3<enter> >=20 > [code-end] >=20 > then, if you execute "depth" it returns 4. > But it should return 3. >=20 > Present definition of "depth" in file "pnuc1" is: > [code-begin] >=20 > : DEPTH > SP0 clearHi32 > SP - 3 a>> ; >=20 > [code-end] >=20 > The definition in PowerMops64-5 or before was: > [code-begin] >=20 > : DEPTH > SP0 SP - 3 a>> ( 2+ ) ; >=20 > [code-end] >=20 > But previous versions don't have the same problem. >=20 > However, I think previous definition would have already been wrong > without optimization. > For it is forgetting to discount an item "SP0" which is pushed onto > stack before getting "SP". > But by optimization of compiler "SP0" is not really pushed > onto stack memory but the calculation is done only on registers, > so?that the problem has never come to the front. >=20 > But a call of new word "clearHi32", though the content of the > word is "null" on 32-bit mode, causes real push of "SP0" on stack. >=20 > Since in the case of 64-bit build "clearHi32" is one inlined > machine instruction, I infer "depth" will return the correct value. >=20 > My trial of fix is as follows: >=20 > [code-begin] >=20 > : DEPTH > SP negate =A5 01/05/06 ns=20 > SP0 clearHi32 + > ( SP - ) 3 a>> ; =A5 01/05/06 ns=20 >=20 > [code-end] >=20 > It works on 32-bit PowerMops. I guess it will work also on 64 bit > PowerMops. >=20 > But then stack display word ".s+" defined in MLTEFwindMod.txt > should be adjusted to this modification. > After some experiments, it turned out that following would fix it. > The definition of "sDepth" in MLTEFwindMod.txt: > [code-begin] >=20 > : sDepth ( -- depth ) =A5 02/12/05 dbh > depth ( actw ^TW <> IF 1+ THEN ) 1+ ; =A5 01/06/06 ns=20 > [code-end] >=20 > But this surely breaks something on 64-bit PowerMops. > (I expect, though, it may not break Doug's fix.) >=20 > Since I have no 64-Bit PPC, that's all what I could do. > Excuse me. >=20 > Sincerely, > Nao Sacrada >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > PowerMops-BETA mailing list > Pow...@li... > https://lists.sourceforge.net/lists/listinfo/powermops-beta ---------------------------------------------------------------- Mike Hore mik...@bi... ---------------------------------------------------------------- |
|
From: Mike H. <mik...@bi...> - 2006-01-07 12:55:46
|
Hi again Nao,
Your fix to DEPTH works, but I also tried defining clearHi32 thus:
64bit?
[IF]
$ BD06 otClearHi32 special_op clearHi32
[ELSE]
: clearHi32 inline{ } ; \ no-op in 32-bit mode
[THEN]
Doing this makes the original DEPTH work as well!
As you said sDepth (in MLTEFwindMod.txt) needs adjustment
-- but for some strange reason it gives a result that differs
by 1 depending on whether we're in 64- or 32-bit mode.
This is what works:
64bit?
[IF]
: sDepth ( -- depth )
depth
;
[ELSE]
: sDepth ( -- depth )
depth 1+ ;
[THEN]
I probably won't bother trying to find why this strange
thing happens -- this code works, and I've got too many other
things to do!!
I've now tried your other code changes you posted over the
last couple of weeks, and everything seems to run fine
in 64-bit mode on the G5.
Cheers, Mike.
----------------------------------------------------------------
Mike Hore mik...@bi...
----------------------------------------------------------------
|
|
From: Mike H. <mik...@bi...> - 2006-01-09 11:08:14
|
Hi all,
This version fixes the focussing anomaly that came up a little
while ago.
enable: and disable: methods are reinstated. disable: calls
TXNFocus with false, so that when the window with the MLTE
view(s) isn't the active window you don't get a flashing
cursor. But it does NOT call the superclass focus: with
false - it doesn't call it at all - so that the containing
window still knows which view is in focus. Thus when the
window is activated again and all its views get enable:,
all the right things happen. The MLTEview, or the correct
MLTEview if there are several, gets TXNFocus called with true,
so you get just one MLTEview with its cursor flashing,
and hopefully it's the right one.
This change seems to give the correct focussing behavior
whether there is one or many MLTEviews in a window.
Cheers, Mike.
----------------------------------------------------------------
Mike Hore mik...@bi...
----------------------------------------------------------------
|
Thanks for helping keep SourceForge clean.
X