Tutorial

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Tutorial

Arie van Wingerden
Hi,

I just wish to explore Pike as a Python alternative.

But the second small program in the tutorial already fails:
Running this:

int main()
{
  GTK.setup_gtk();
  GTK.Alert("Hello world!", "Title");
  return -1;
}

Gives this result:

E:/src/pike/test.pike:4:Index 'Alert' not present in module GTK.
E:/src/pike/test.pike:4:Indexed module was: GTK.
E:/src/pike/test.pike:4:Too many arguments to `() (function call) (expected 0 arguments).
E:/src/pike/test.pike:4:Got     : string(32..119).
Pike: Failed to compile script.

On OSDir I found that maybe I should install GTK separately. Also in the docs I see references to GTK1 and GTK2.

Q1: Which GTK version is appropriate for Windows?

Q2: is there a Pike package manager for this kind of thing?

Best regards,
   Arie
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tutorial

Chris Angelico
On Thu, Dec 8, 2016 at 10:16 PM, Arie van Wingerden <[hidden email]> wrote:

> Hi,
>
> I just wish to explore Pike as a Python alternative.
>
> But the second small program in the tutorial already fails:
> Running this:
>
> int main()
> {
>   GTK.setup_gtk();
>   GTK.Alert("Hello world!", "Title");
>   return -1;
> }
>
> Gives this result:
>
> E:/src/pike/test.pike:4:Index 'Alert' not present in module GTK.
> E:/src/pike/test.pike:4:Indexed module was: GTK.
> E:/src/pike/test.pike:4:Too many arguments to `() (function call) (expected
> 0 arguments).
> E:/src/pike/test.pike:4:Got     : string(32..119).
> Pike: Failed to compile script.
>
> On OSDir I found that maybe I should install GTK separately. Also in the
> docs I see references to GTK1 and GTK2.
>
> Q1: Which GTK version is appropriate for Windows?
>
> Q2: is there a Pike package manager for this kind of thing?

Oh... yeah, sorry about that. The GTK tutorial is way out of date.
It's been on my TODO list for ages, but that doesn't really help much.

Here's a GTK2 hello-world:

int main()
{
    GTK2.setup_gtk();
    GTK2.MessageDialog(0, 0, GTK2.BUTTONS_OK, "Hello, world!")->show();
    return -1;
}

Yes, it's not as short as the GTK.Alert form, but MessageDialog does a
lot more. If you want more of a language-level Hello World, try this:

int main()
{
    write("Hello, world!\n");
}

Check out my GitHub repositories for some cool stuff you can do with Pike.

https://github.com/Rosuav

I use it for back-end work (although you won't see all of that there,
as my biggest projects aren't public), GUI applications (Gypsum,
StilleBot, Zawinski), data processing scripts, file management tools,
and all manner of one-shot scripts. Pike stands alongside Python in my
toolbox of easy and convenient languages.

If you want to get into GTK work, definitely use GTK2 (Pike doesn't
have GTK3 bindings as yet, and GTK1 isn't worth hanging onto), but on
Windows, that means you have to choose between the latest Pike with a
slightly older GTK, and the latest GTK on a slightly older Pike. I
recommend the former, until such time as you run into a problem.

Have fun learning Pike! It's a great language.

ChrisA

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tutorial

Arie van Wingerden
2016-12-08 14:04 GMT+01:00 Chris Angelico <[hidden email]>:
Oh... yeah, sorry about that. The GTK tutorial is way out of date.
It's been on my TODO list for ages, but that doesn't really help much.

​I see ...​

 

Here's a GTK2 hello-world:

int main()
{
    GTK2.setup_gtk();
    GTK2.MessageDialog(0, 0, GTK2.BUTTONS_OK, "Hello, world!")->show();
    return -1;
}


​Nice! That works out of the box - so no need for extra GTK installs etc.

So, I guess the API for GTK has changed and dropped the Alert function then?

Check out my GitHub repositories for some cool stuff you can do with Pike.

https://github.com/Rosuav

​Will certainly check out.​

QUESTION: is Pike self-contained in the sense that all module functionality is included (so, no extra installs needed to function)?

Reason is that Python is so difficult to deploy. If I can:
1. install Pike for somebody
2. hand them a Pike script
and then the script runs right out of the box, that would be a huge improvement over the Python way, where you have to 'pip install' a lot of extra stuff in many cases ...!

Thx for helping!




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tutorial

Arie van Wingerden
Hi Chris,

the example with the webbrowser does not work as designed in Windows.

When the URL is entered from Stdin it contains CRLF.
After doing this it works:
     handle_url(String.trim_all_whites(url));

Best regards,
   Arie

2016-12-08 15:01 GMT+01:00 Arie van Wingerden <[hidden email]>:
2016-12-08 14:04 GMT+01:00 Chris Angelico <[hidden email]>:
Oh... yeah, sorry about that. The GTK tutorial is way out of date.
It's been on my TODO list for ages, but that doesn't really help much.

​I see ...​

 

Here's a GTK2 hello-world:

int main()
{
    GTK2.setup_gtk();
    GTK2.MessageDialog(0, 0, GTK2.BUTTONS_OK, "Hello, world!")->show();
    return -1;
}


​Nice! That works out of the box - so no need for extra GTK installs etc.

So, I guess the API for GTK has changed and dropped the Alert function then?

Check out my GitHub repositories for some cool stuff you can do with Pike.

https://github.com/Rosuav

​Will certainly check out.​

QUESTION: is Pike self-contained in the sense that all module functionality is included (so, no extra installs needed to function)?

Reason is that Python is so difficult to deploy. If I can:
1. install Pike for somebody
2. hand them a Pike script
and then the script runs right out of the box, that would be a huge improvement over the Python way, where you have to 'pip install' a lot of extra stuff in many cases ...!

Thx for helping!





Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tutorial

Chris Angelico
In reply to this post by Arie van Wingerden
On Fri, Dec 9, 2016 at 1:01 AM, Arie van Wingerden <[hidden email]> wrote:
>
> QUESTION: is Pike self-contained in the sense that all module functionality
> is included (so, no extra installs needed to function)?

On Windows, you get a single .msi file and that contains all of Pike.
On Mac OS, I haven't pinned it down yet, but I *think* that installing
XQuartz followed by Pike will give everything you need. (It has to be
two steps because of XQuartz licensing terms. Thanks Apple.) On Linux,
it depends on your distribution; you can often use your package
manager to get "pike8.0-full" to get it all.

> Reason is that Python is so difficult to deploy. If I can:
> 1. install Pike for somebody
> 2. hand them a Pike script
> and then the script runs right out of the box, that would be a huge
> improvement over the Python way, where you have to 'pip install' a lot of
> extra stuff in many cases ...!

Agreed. Here's what I have for the installation instructions for my
Pike-implemented MUD client (which uses GTK2):

http://rosuav.github.io/Gypsum/INSTALL

(It actually installs Pike 7.8.866 because it's easier to support the
older Pike than the older GTK, due to the specific needs of Gypsum.)

With Python, I would normally distribute something that either needs
nothing more than the base installation (so it's the same as Pike), or
has a requirements.txt, so you simply run "pip install -r
requirements.txt" to get everything. Pike does also have a package
manager (called monger), but it's used far less than Python's is. For
starters, you actually get a decent GUI toolkit out-of-the-box,
instead of having to choose between Tkinter (which mostly sucks) and
anything else (which you have to get using pip). :)

There's a reason I do all my GUI programming in Pike these days :)

ChrisA

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tutorial

Stephen R. van den Berg
In reply to this post by Arie van Wingerden
Arie van Wingerden wrote:
>QUESTION: is Pike self-contained in the sense that all module functionality
>is included (so, no extra installs needed to function)?

>Reason is that Python is so difficult to deploy. If I can:
>1. install Pike for somebody
>2. hand them a Pike script
>and then the script runs right out of the box, that would be a huge
>improvement over the Python way, where you have to 'pip install' a lot of
>extra stuff in many cases ...!

Differences between Pike and Python/Perl/Ruby at module level are
that Python/Perl/Ruby typically have a much larger userbase, and thus
more contributors, and thus a much larger number of add-on modules/libraries;
on the contrary Pike has are larger number of modules that are part
of the core distribution, and the quality of implementation of those
core distribution modules on general is much higher than the myriad of
add-on modules for Python/Perl/Ruby.

So, yes, that would/could mean that a standard Pike install is more
complete than a standard Python install.
YMMV, though.
--
Stephen.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tutorial

Chris Angelico
In reply to this post by Arie van Wingerden
On Fri, Dec 9, 2016 at 1:26 AM, Arie van Wingerden <[hidden email]> wrote:
> Hi Chris,
>
> the example with the webbrowser does not work as designed in Windows.
>
> When the URL is entered from Stdin it contains CRLF.
> After doing this it works:
>      handle_url(String.trim_all_whites(url));
>

Hmm, where's that example? That one's a pretty straight-forward fix.

ChrisA

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tutorial

Leif Stensson, Lysator @ Pike  importmöte för mailinglistan
It sounds a bit like stdin (line-iterator?) is handled differently in
Windows?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tutorial

Arie van Wingerden
In reply to this post by Chris Angelico
Hi Chris,

in "Your second Pike program" starting from "Command-line Arguments and if".

Maybe it's a Windows issue. At the moment I can't test in other OS ...

Thx,
   Arie

2016-12-08 16:05 GMT+01:00 Mirar @ Pike importmöte för mailinglistan <[hidden email]>:
It sounds a bit like stdin (line-iterator?) is handled differently in
Windows?


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tutorial

Peter Bortas-2
Since I happened to have my Windows VM console up: I can confirm this
behavior in the default Hilfe:

> Stdio.stdin->gets();
foo
(1) Result: "foo\r"

That seems rather useless. It would break the API to fix it, but on
the other hand gets() is one of those functions you almost only use in
tutorials.

--
Peter Bortas



On Thu, Dec 8, 2016 at 4:57 PM, Arie van Wingerden <[hidden email]> wrote:

> Hi Chris,
>
> here: https://pike.lysator.liu.se/docs/tutorial/
> in "Your second Pike program" starting from "Command-line Arguments and if".
>
> Maybe it's a Windows issue. At the moment I can't test in other OS ...
>
> Thx,
>    Arie
>
> 2016-12-08 16:05 GMT+01:00 Mirar @ Pike importmöte för mailinglistan
> <[hidden email]>:
>>
>> It sounds a bit like stdin (line-iterator?) is handled differently in
>> Windows?
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tutorial

Chris Angelico
On Fri, Dec 9, 2016 at 3:32 AM, Peter Bortas <[hidden email]> wrote:

> Since I happened to have my Windows VM console up: I can confirm this
> behavior in the default Hilfe:
>
>> Stdio.stdin->gets();
> foo
> (1) Result: "foo\r"
>
> That seems rather useless. It would break the API to fix it, but on
> the other hand gets() is one of those functions you almost only use in
> tutorials.

Would it break the API? I mean, conceptually, it's retrieving a string
terminated by end-of-line. On Windows, "end-of-line" is often "\r\n".
Perhaps the solution is for gets to always strip off a trailing \r?
Bear in mind that this also applies to files that have CRLF endings,
not just stdin. I normally get around it by trimming whites, but it'd
be nice for it to just work.

ChrisA

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tutorial

Pontus Östlund
In reply to this post by Arie van Wingerden

8 dec. 2016 kl. 16:57 skrev Arie van Wingerden <[hidden email]>:

[...]
in "Your second Pike program" starting from "Command-line Arguments and if".
[...]

Speaking of which! For the new Pike site I have a revamped version of the tutorial (not the content thogh) which uses the markdown-files from https://github.com/pikelang/tutorial. If we (Grubba wink wink) only clone that repo somewhere on the server and set up a cronjob that pulls from there now and then, anybody could clone the Github repo and contribute to the tutorial. That would be nice.

# Pontus

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tutorial

Arie van Wingerden
In reply to this post by Stephen R. van den Berg

OK, then i'm right on track  ... Thx.


On Dec 8, 2016 3:40 PM, "Stephen R. van den Berg" <[hidden email]> wrote:
Arie van Wingerden wrote:
>QUESTION: is Pike self-contained in the sense that all module functionality
>is included (so, no extra installs needed to function)?

>Reason is that Python is so difficult to deploy. If I can:
>1. install Pike for somebody
>2. hand them a Pike script
>and then the script runs right out of the box, that would be a huge
>improvement over the Python way, where you have to 'pip install' a lot of
>extra stuff in many cases ...!

Differences between Pike and Python/Perl/Ruby at module level are
that Python/Perl/Ruby typically have a much larger userbase, and thus
more contributors, and thus a much larger number of add-on modules/libraries;
on the contrary Pike has are larger number of modules that are part
of the core distribution, and the quality of implementation of those
core distribution modules on general is much higher than the myriad of
add-on modules for Python/Perl/Ruby.

So, yes, that would/could mean that a standard Pike install is more
complete than a standard Python install.
YMMV, though.
--
Stephen.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tutorial

Leif Stensson, Lysator @ Pike  importmöte för mailinglistan
In reply to this post by Peter Bortas-2
It's "foo" under Linux, so it seems Windows gets() is broken?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tutorial

Stephen R. van den Berg
In reply to this post by Chris Angelico
Chris Angelico wrote:
>>> Stdio.stdin->gets();
>> foo
>> (1) Result: "foo\r"

>> That seems rather useless. It would break the API to fix it, but on
>> the other hand gets() is one of those functions you almost only use in
>> tutorials.

>Would it break the API? I mean, conceptually, it's retrieving a string
>terminated by end-of-line. On Windows, "end-of-line" is often "\r\n".

C89 specifies that this normally is solved by the distinction between
binary and ascii streams/files.

Opening with mode 'b' specifies a binary file, without a 'b' is an ascii file
(which on Windows means that line endings of \n are transparently converted
back and forth to \r\n on writing and reading).
See "man 3 fopen".
Pike should be able to put stdin into ascii mode to activate this behaviour.
--
Stephen.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tutorial

Stephen R. van den Berg
Stephen R. van den Berg wrote:
>Pike should be able to put stdin into ascii mode to activate this behaviour.

Maybe this can be implicit when selecting a character set.
Selecting a character set is necessary to get correctly behaving stdin,
and setting a characterset implies that it is not a binary file and thus
EOL conversion should be activated.
--
Stephen.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tutorial

Leif Stensson, Lysator @ Pike  importmöte för mailinglistan
In reply to this post by Stephen R. van den Berg
We don't have to adhere to C standard in Pike, and if it shouldn't
contain the line termination it shouldn't do that under any OS,
in my opinion.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tutorial

Peter Bortas-2
In reply to this post by Chris Angelico
On Thu, Dec 8, 2016 at 7:08 PM, Chris Angelico <[hidden email]> wrote:

> On Fri, Dec 9, 2016 at 3:32 AM, Peter Bortas <[hidden email]> wrote:
>> Since I happened to have my Windows VM console up: I can confirm this
>> behavior in the default Hilfe:
>>
>>> Stdio.stdin->gets();
>> foo
>> (1) Result: "foo\r"
>>
>> That seems rather useless. It would break the API to fix it, but on
>> the other hand gets() is one of those functions you almost only use in
>> tutorials.
>
> Would it break the API? I mean, conceptually, it's retrieving a string
> terminated by end-of-line. On Windows, "end-of-line" is often "\r\n".
> Perhaps the solution is for gets to always strip off a trailing \r?
> Bear in mind that this also applies to files that have CRLF endings,
> not just stdin. I normally get around it by trimming whites, but it'd
> be nice for it to just work.

It would not break the documented API, but it would change what gets()
returns on all OS. Maybe someone somewhere is feeding gets() with
deliberate \r's at the end. To clarify: I am argumenting for breaking
it though. Maybe even before 8.2.

Speaking of silly functions, has anyone ever used ->ngets()?

--
Peter Bortas

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tutorial

Chris Angelico
On Fri, Dec 9, 2016 at 9:22 AM, Peter Bortas <[hidden email]> wrote:

>> Would it break the API? I mean, conceptually, it's retrieving a string
>> terminated by end-of-line. On Windows, "end-of-line" is often "\r\n".
>> Perhaps the solution is for gets to always strip off a trailing \r?
>> Bear in mind that this also applies to files that have CRLF endings,
>> not just stdin. I normally get around it by trimming whites, but it'd
>> be nice for it to just work.
>
> It would not break the documented API, but it would change what gets()
> returns on all OS. Maybe someone somewhere is feeding gets() with
> deliberate \r's at the end. To clarify: I am argumenting for breaking
> it though. Maybe even before 8.2.

Gotcha. Yeah, I understand that this shouldn't be changed in 8.0, just
because it is an incompatibility. But it's fulfilling the concept of
the function, so yep, change it in 8.1 IMO.

ChrisA

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tutorial

Peter Bortas-2
On Thu, Dec 8, 2016 at 11:33 PM, Chris Angelico <[hidden email]> wrote:

> On Fri, Dec 9, 2016 at 9:22 AM, Peter Bortas <[hidden email]> wrote:
>>> Would it break the API? I mean, conceptually, it's retrieving a string
>>> terminated by end-of-line. On Windows, "end-of-line" is often "\r\n".
>>> Perhaps the solution is for gets to always strip off a trailing \r?
>>> Bear in mind that this also applies to files that have CRLF endings,
>>> not just stdin. I normally get around it by trimming whites, but it'd
>>> be nice for it to just work.
>>
>> It would not break the documented API, but it would change what gets()
>> returns on all OS. Maybe someone somewhere is feeding gets() with
>> deliberate \r's at the end. To clarify: I am argumenting for breaking
>> it though. Maybe even before 8.2.
>
> Gotcha. Yeah, I understand that this shouldn't be changed in 8.0, just
> because it is an incompatibility. But it's fulfilling the concept of
> the function, so yep, change it in 8.1 IMO.

With before 8.2 I meant potentially in 8.0. :)

Reason being I can come up with plausible (but stupid) scenarios where
this could break something, but gets is a silly function that never
gets used except in the tutorial. Having a working tutorial is good.

Or we fix the tutorial. With say, Readline? (Please Readline, don't be
broken on Windows...)

--
Peter Bortas

12
Loading...