WMF question

FredBlais

I'm doing a program that is lauching WMF in another cog and continue the execution of the main cog.
The main program is supposed to post a message in the buffer VAR so the WMF can print it to the screen.
Everything seems to work well, the string is printed.
However, the main cog hang after the cognew command, the LED at pin 0 is never lit...
If I comment the cognew, execution is continuing...
Someone has a clue?
Thanks

CON
  _clkmode = xtal2 + pll8x
  _xinfreq = 10_000_000
  
OBJ
  term : "Terminal"
  
VAR
  byte Buffer[32]
  long Stack[32]

  
PUB Start
  dira[0]~~ 
  Message(string("TEST"))
  cognew(term.Start(@Buffer), @Stack)
  outa[0]~~ ' Light LED
  ...

PRI Message(pString)
  bytemove(@Buffer, pString, strsize(pString)+1)  

Rayman

Stack[32] is sometimes not enough... But, I don't think that's the problem.

You should end your Start routine with a "repeat" (infinite loop). Otherwise, the main cog will shut itself down.

FredBlais

Rayman wrote: »

Stack[32] is sometimes not enough... But, I don't think that's the problem.

You should end your Start routine with a "repeat" (infinite loop). Otherwise, the main cog will shut itself down.

Yup I tried the two but this is not the problem.
Even when the main cog hang, the WMF is doing fine, mouse and keyboard responsive etc...

Kye

Cognew can't be called on a method not in the current object. Make a wrapper for the metnod and then call it with cognew.

Rayman

Kye is right, of course. That's your real problem. Still, I think you'll need the "repeat" and the end of "Pub Start".

FredBlais

Kye wrote: »

Cognew can't be called on a method not in the current object. Make a wrapper for the metnod and then call it with cognew.

You were right Kye,
Thanks

Kevin McCullough

I've submitted this to our issue-tracking system.

kuroneko

Kevin McCullough wrote: »

I've submitted this to our issue-tracking system.

I assume that's to improve the documentation!? While you're at it, don't just nail a STOP sign in front of it. The syntax is perfectly usable for selectively starting PASM cogs (method call returns the address).

Kevin McCullough

kuroneko wrote: »

I assume that's to improve the documentation!? While you're at it, don't just nail a STOP sign in front of it. The syntax is perfectly usable for selectively starting PASM cogs (method call returns the address).

Is there something I'm missing? I'm detecting a lot of aggression in your post, and for what purpose I'm not quite sure...

The issue of cognew only working for methods within the current object has the potential to cause confusion and wasted time. To avoid that, I would think we should either provide better notes in our documentation, and/or make the Propeller Tool catch these scenarios and issue a useful error/warning. If you have a different suggestion, I would be happy to include that with our notes for when we go to make the updates.

kuroneko

Kevin McCullough wrote: »

Is there something I'm missing? I'm detecting a lot of aggression in your post, and for what purpose I'm not quite sure...

Apologies. That wasn't my intention.

Having read the recent updates to the documention I still see too many notes which seem to discourage a certain usage pattern (I flagged that up last year already). Given the initial answers in this thread (can't be called) I was afraid that the solution will be to add a note saying don't do this. That's only half the truth. So why not list what is possible and leave the decision of how to do it to the user?

FredBlais

Kevin McCullough wrote: »

The issue of cognew only working for methods within the current object has the potential to cause confusion and wasted time. To avoid that, I would think we should either provide better notes in our documentation, and/or make the Propeller Tool catch these scenarios and issue a useful error/warning.

thanks Kevin,
I felt that this issue was an unwritten rule. Raising a warning would be perfect to inform the user about this.