FFI | <apicall ...> <cdecl ...> styling: Tools or Kernel?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

FFI | <apicall ...> <cdecl ...> styling: Tools or Kernel?

marcel.taeumel
Hi all!

I just extracted FFI-specific code for pragma styling into the FFI-Tools package.

I am not sure whether this is good, because now you *have to* load that FFI-Tools package to browse method sources with FFI pragmas having Shout enabled. So, that's a change. All my other additions to FFI-Tools have been new so far.

Having FFI-Pools and FFI-Kernel only lets you compile this method:


After installing FFI-Tools, you get this experience:


Here is another take on package organization for the Squeak FFI project:

Please share your thoughts on this matter :-)

Best,
Marcel


Reply | Threaded
Open this post in threaded view
|

Re: FFI | <apicall ...> <cdecl ...> styling: Tools or Kernel?

Jakob Reschke
Hi Marcel,

Could we have a fallback implementation in Tools that just ignores/does not highlight the contents of any <...> at the top of the method?

And if you load the appropriate tools package for your feature (FFI), then you get better styling for the constructs it supplies.

Kind regards,
Jakob


Am So., 14. Juni 2020 um 08:29 Uhr schrieb Marcel Taeumel <[hidden email]>:
Hi all!

I just extracted FFI-specific code for pragma styling into the FFI-Tools package.

I am not sure whether this is good, because now you *have to* load that FFI-Tools package to browse method sources with FFI pragmas having Shout enabled. So, that's a change. All my other additions to FFI-Tools have been new so far.

Having FFI-Pools and FFI-Kernel only lets you compile this method:


After installing FFI-Tools, you get this experience:


Here is another take on package organization for the Squeak FFI project:

Please share your thoughts on this matter :-)

Best,
Marcel



Reply | Threaded
Open this post in threaded view
|

Re: FFI | <apicall ...> <cdecl ...> styling: Tools or Kernel?

marcel.taeumel
Hi Jakob.

Could we have a fallback implementation

Hmm... not a robust one. The current fallback is to parse the standard keyword pattern: <foo: 42 bar: 'huh' baz: #hmm>

As soon as a custom pragma parser comes into play --- like the one for FFI calls --- you can only "fail" as a Shout parser if you come across an unexpected token.

Well, when parsing pragmas, we could implement a different kind of #fail. We could look for the next > and try to finish parsing the pragma. This would only work if there is no other > in the middle ... #> and '>' are fine, I suppose.

Best,
Marcel

Am 14.06.2020 23:46:48 schrieb Jakob Reschke <[hidden email]>:

Hi Marcel,

Could we have a fallback implementation in Tools that just ignores/does not highlight the contents of any <...> at the top of the method?

And if you load the appropriate tools package for your feature (FFI), then you get better styling for the constructs it supplies.

Kind regards,
Jakob


Am So., 14. Juni 2020 um 08:29 Uhr schrieb Marcel Taeumel <[hidden email]>:
Hi all!

I just extracted FFI-specific code for pragma styling into the FFI-Tools package.

I am not sure whether this is good, because now you *have to* load that FFI-Tools package to browse method sources with FFI pragmas having Shout enabled. So, that's a change. All my other additions to FFI-Tools have been new so far.

Having FFI-Pools and FFI-Kernel only lets you compile this method:


After installing FFI-Tools, you get this experience:


Here is another take on package organization for the Squeak FFI project:

Please share your thoughts on this matter :-)

Best,
Marcel



Reply | Threaded
Open this post in threaded view
|

Re: FFI | <apicall ...> <cdecl ...> styling: Tools or Kernel?

marcel.taeumel
Hi Jakob.

Or did you mean a fall-back in the FFI-Kernel package? Well, you can always disable styling.

Well, if you cannot save/compile the source anyway, it makes no sense to implement a fallback in Shout for arbitrary stuff in a pragma.

Best,
Marcel

Am 15.06.2020 09:35:18 schrieb Marcel Taeumel <[hidden email]>:

Hi Jakob.

Could we have a fallback implementation

Hmm... not a robust one. The current fallback is to parse the standard keyword pattern: <foo: 42 bar: 'huh' baz: #hmm>

As soon as a custom pragma parser comes into play --- like the one for FFI calls --- you can only "fail" as a Shout parser if you come across an unexpected token.

Well, when parsing pragmas, we could implement a different kind of #fail. We could look for the next > and try to finish parsing the pragma. This would only work if there is no other > in the middle ... #> and '>' are fine, I suppose.

Best,
Marcel

Am 14.06.2020 23:46:48 schrieb Jakob Reschke <[hidden email]>:

Hi Marcel,

Could we have a fallback implementation in Tools that just ignores/does not highlight the contents of any <...> at the top of the method?

And if you load the appropriate tools package for your feature (FFI), then you get better styling for the constructs it supplies.

Kind regards,
Jakob


Am So., 14. Juni 2020 um 08:29 Uhr schrieb Marcel Taeumel <[hidden email]>:
Hi all!

I just extracted FFI-specific code for pragma styling into the FFI-Tools package.

I am not sure whether this is good, because now you *have to* load that FFI-Tools package to browse method sources with FFI pragmas having Shout enabled. So, that's a change. All my other additions to FFI-Tools have been new so far.

Having FFI-Pools and FFI-Kernel only lets you compile this method:


After installing FFI-Tools, you get this experience:


Here is another take on package organization for the Squeak FFI project:

Please share your thoughts on this matter :-)

Best,
Marcel



Reply | Threaded
Open this post in threaded view
|

Re: FFI | <apicall ...> <cdecl ...> styling: Tools or Kernel?

Jakob Reschke
I meant a fallback not in FFI-Kernel and to "skip" the body of unknown
pragmas (or thinks that look like pragmas), so they don't turn red
when you view them. You can compile them if you have FFI-Kernel, but
not FFI-Tools, right?

Am Mo., 15. Juni 2020 um 09:49 Uhr schrieb Marcel Taeumel
<[hidden email]>:

>
> Hi Jakob.
>
> Or did you mean a fall-back in the FFI-Kernel package? Well, you can always disable styling.
>
> Well, if you cannot save/compile the source anyway, it makes no sense to implement a fallback in Shout for arbitrary stuff in a pragma.
>
> Best,
> Marcel
>
> Am 15.06.2020 09:35:18 schrieb Marcel Taeumel <[hidden email]>:
>
> Hi Jakob.
>
> > Could we have a fallback implementation
>
> Hmm... not a robust one. The current fallback is to parse the standard keyword pattern: <foo: 42 bar: 'huh' baz: #hmm>
>
> As soon as a custom pragma parser comes into play --- like the one for FFI calls --- you can only "fail" as a Shout parser if you come across an unexpected token.
>
> Well, when parsing pragmas, we could implement a different kind of #fail. We could look for the next > and try to finish parsing the pragma. This would only work if there is no other > in the middle ... #> and '>' are fine, I suppose.
>
> Best,
> Marcel
>
> Am 14.06.2020 23:46:48 schrieb Jakob Reschke <[hidden email]>:
>
> Hi Marcel,
>
> Could we have a fallback implementation in Tools that just ignores/does not highlight the contents of any <...> at the top of the method?
>
> And if you load the appropriate tools package for your feature (FFI), then you get better styling for the constructs it supplies.
>
> Kind regards,
> Jakob
>
>
> Am So., 14. Juni 2020 um 08:29 Uhr schrieb Marcel Taeumel <[hidden email]>:
>>
>> Hi all!
>>
>> I just extracted FFI-specific code for pragma styling into the FFI-Tools package.
>>
>> I am not sure whether this is good, because now you *have to* load that FFI-Tools package to browse method sources with FFI pragmas having Shout enabled. So, that's a change. All my other additions to FFI-Tools have been new so far.
>>
>> Having FFI-Pools and FFI-Kernel only lets you compile this method:
>>
>>
>> After installing FFI-Tools, you get this experience:
>>
>>
>> Here is another take on package organization for the Squeak FFI project:
>> http://forum.world.st/FFI-FFI-Pools-mt-19-mcz-tp5117611p5117643.html
>>
>> Please share your thoughts on this matter :-)
>>
>> Best,
>> Marcel
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: FFI | <apicall ...> <cdecl ...> styling: Tools or Kernel?

marcel.taeumel
So, Shout should provide a fallback for arbitrary pragmas to then continue parsing other pragmas or the regular method body?

Best,
Marcel

Am 15.06.2020 11:22:51 schrieb Jakob Reschke <[hidden email]>:

I meant a fallback not in FFI-Kernel and to "skip" the body of unknown
pragmas (or thinks that look like pragmas), so they don't turn red
when you view them. You can compile them if you have FFI-Kernel, but
not FFI-Tools, right?

Am Mo., 15. Juni 2020 um 09:49 Uhr schrieb Marcel Taeumel
:
>
> Hi Jakob.
>
> Or did you mean a fall-back in the FFI-Kernel package? Well, you can always disable styling.
>
> Well, if you cannot save/compile the source anyway, it makes no sense to implement a fallback in Shout for arbitrary stuff in a pragma.
>
> Best,
> Marcel
>
> Am 15.06.2020 09:35:18 schrieb Marcel Taeumel :
>
> Hi Jakob.
>
> > Could we have a fallback implementation
>
> Hmm... not a robust one. The current fallback is to parse the standard keyword pattern:
>
> As soon as a custom pragma parser comes into play --- like the one for FFI calls --- you can only "fail" as a Shout parser if you come across an unexpected token.
>
> Well, when parsing pragmas, we could implement a different kind of #fail. We could look for the next > and try to finish parsing the pragma. This would only work if there is no other > in the middle ... #> and '>' are fine, I suppose.
>
> Best,
> Marcel
>
> Am 14.06.2020 23:46:48 schrieb Jakob Reschke :
>
> Hi Marcel,
>
> Could we have a fallback implementation in Tools that just ignores/does not highlight the contents of any <...> at the top of the method?
>
> And if you load the appropriate tools package for your feature (FFI), then you get better styling for the constructs it supplies.
>
> Kind regards,
> Jakob
>
>
> Am So., 14. Juni 2020 um 08:29 Uhr schrieb Marcel Taeumel :
>>
>> Hi all!
>>
>> I just extracted FFI-specific code for pragma styling into the FFI-Tools package.
>>
>> I am not sure whether this is good, because now you *have to* load that FFI-Tools package to browse method sources with FFI pragmas having Shout enabled. So, that's a change. All my other additions to FFI-Tools have been new so far.
>>
>> Having FFI-Pools and FFI-Kernel only lets you compile this method:
>>
>>
>> After installing FFI-Tools, you get this experience:
>>
>>
>> Here is another take on package organization for the Squeak FFI project:
>> http://forum.world.st/FFI-FFI-Pools-mt-19-mcz-tp5117611p5117643.html
>>
>> Please share your thoughts on this matter :-)
>>
>> Best,
>> Marcel
>>
>



Reply | Threaded
Open this post in threaded view
|

Re: FFI | <apicall ...> <cdecl ...> styling: Tools or Kernel?

Jakob Reschke
If you agree that it makes sense, yes it should.


Marcel Taeumel <[hidden email]> schrieb am Mo., 15. Juni 2020, 11:25:
So, Shout should provide a fallback for arbitrary pragmas to then continue parsing other pragmas or the regular method body?

Best,
Marcel

Am 15.06.2020 11:22:51 schrieb Jakob Reschke <[hidden email]>:

I meant a fallback not in FFI-Kernel and to "skip" the body of unknown
pragmas (or thinks that look like pragmas), so they don't turn red
when you view them. You can compile them if you have FFI-Kernel, but
not FFI-Tools, right?

Am Mo., 15. Juni 2020 um 09:49 Uhr schrieb Marcel Taeumel
:

>
> Hi Jakob.
>
> Or did you mean a fall-back in the FFI-Kernel package? Well, you can always disable styling.
>
> Well, if you cannot save/compile the source anyway, it makes no sense to implement a fallback in Shout for arbitrary stuff in a pragma.
>
> Best,
> Marcel
>
> Am 15.06.2020 09:35:18 schrieb Marcel Taeumel :
>
> Hi Jakob.
>
> > Could we have a fallback implementation
>
> Hmm... not a robust one. The current fallback is to parse the standard keyword pattern:
>
> As soon as a custom pragma parser comes into play --- like the one for FFI calls --- you can only "fail" as a Shout parser if you come across an unexpected token.
>
> Well, when parsing pragmas, we could implement a different kind of #fail. We could look for the next > and try to finish parsing the pragma. This would only work if there is no other > in the middle ... #> and '>' are fine, I suppose.
>
> Best,
> Marcel
>
> Am 14.06.2020 23:46:48 schrieb Jakob Reschke :
>
> Hi Marcel,
>
> Could we have a fallback implementation in Tools that just ignores/does not highlight the contents of any <...> at the top of the method?
>
> And if you load the appropriate tools package for your feature (FFI), then you get better styling for the constructs it supplies.
>
> Kind regards,
> Jakob
>
>
> Am So., 14. Juni 2020 um 08:29 Uhr schrieb Marcel Taeumel :
>>
>> Hi all!
>>
>> I just extracted FFI-specific code for pragma styling into the FFI-Tools package.
>>
>> I am not sure whether this is good, because now you *have to* load that FFI-Tools package to browse method sources with FFI pragmas having Shout enabled. So, that's a change. All my other additions to FFI-Tools have been new so far.
>>
>> Having FFI-Pools and FFI-Kernel only lets you compile this method:
>>
>>
>> After installing FFI-Tools, you get this experience:
>>
>>
>> Here is another take on package organization for the Squeak FFI project:
>> http://forum.world.st/FFI-FFI-Pools-mt-19-mcz-tp5117611p5117643.html
>>
>> Please share your thoughts on this matter :-)
>>
>> Best,
>> Marcel
>>
>