Pike-devel January 2004

pike-devel@lists.lysator.liu.se

11 participants
77 discussions

Start a nNew thread

lost fds
by Mirar ＠ Pike developers forum 11 Jan '04

11 Jan '04

How did you track down lost fds, again? (Protocols.Bittorrents eat them all.)

2 1

C#-like properties
by Marcus Agehall (Scanian) ＠ Pike (-) developers forum 11 Jan '04

11 Jan '04

While working on my master thesis, I have once again discovered the many similarities between C# and Pike. With the C# spec 2.0, C# will become even more Pike-like and for example introduce lambda expressions. At present, there is one thing in C# which I would very much like to see in Pike. C# has a concept called property. It's a mix of a variable and methods to get and set that variable. It is considered good OO-practise to hide variables and use methods to access them but this causes a lot of polution within the namespace of a class with a log of variables if each one must have a getFoo() and a setFoo() method. Here is how to do it the C# way: private int foo; public int Foo { get { return foo; } set { foo = value; } } To access the Foo property, one just uses it just like a normal variable: int x = Foo; Foo = x+1; C# appears to implement this by turning the property into two methods, which in the example above would be called get_Foo() and set_Foo(). These methods cannot be called directly by the code, attempts to do so causes a compilation error. In my sample, there is not much use in having a property, since no processing of the value is done, but in real life situations, there are many times I found that I may want to limit the value set by the caller to a certain range or similar. This is easily done with properties in C#. Ofcourse, the problem can be solved by implementing the get and set methods manually, as one does today, but I believe that the C# way is much better looking and, at least to me, feels more natural. My suggestion is that we put implementation of a C#-like property concept on the TODO-list. Thoughts, other ideas?

15 54

sscanf()
by Credence Shanden 10 Jan '04

10 Jan '04

Hello it seems as if I am having a tiny little problem with sscanf(). I am trying to match the input given to a string via sscanf. It's a simple little deal but the format I am using obviously isn't working although it has in the past. Here is the code snippet: if(sscanf("quit", sCommand + "%*s")) Now what I am trying to accomplish is to see if the player typed anything pertaining to the word quit. I.E q, qu, qui or even quit itself....Yes why not do a simple if/else. Well because there will be other commands that can be executed that will be longer. Am I setting this up wrong? It has worked in the past outside of pike but still in LPC. I even tried search("quit", sCommand) and that seemed to only return -1 no matter what I typed. Thanks in advance all. --------------------------------- Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes

2 4

NettleNettle???
by Martin Bähr 09 Jan '04

09 Jan '04

while looking at the putty links i discovered: http://nettlessh.mine.nu/ with the interresting thing that nettle itself: http://nettle.sourceforge.net/ has nothing to do with crypto. one could presumably combine the nettle terminal with the nettle crypto lib and create: nettlenettle ;-))) greetings, martin.

3 3

array[*]->method(), bug?
by Mark Tlay 06 Jan '04

06 Jan '04

While playing with automap I noticed: array[*]["method"](); works, but: array[*]->method(); does not work. I think this should be a bug. Thoughts? __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

2 1

Re: #include
by Credence Shanden 06 Jan '04

06 Jan '04

Sorry sent this last message directly to Martin my apologies. So now I will send it to the whole list. Credence Shanden <gm_credence(a)yahoo.com> wrote:Does it prepend the path with the current files path? I know import does this, does include do this also? With this application I am trying to include a file that is in c:/emage/includes/kernel.h from c:/emage/lib/obj/std/login.pike. Would this make the include path c:/emage/lib/obj/std to start with? "Martin Nilsson (saturator) @ Pike (-) developers forum" <10353(a)lyskom.lysator.liu.se> wrote: There is nothing magic with #include, so I don't know what answer you expect. If it can't read the file then it can't read the file (no permission or couldn't find it). That's all there is to it. / Martin Nilsson (saturator) Previous text: >2004-01-06 07:35: >Subject: #include >-------------------------------------------------------------------- >Well this is my first attempt with PIKE, although I am familiar with the LPC language some things seem to be a bit different in PIKE. My problem is that I am trying to include a file but I get the error that the file could not be read. I am assuming that somehow I am typing the directory wrong. I have tried many different ways including typing out the full directory name. I have kernel.pike which is the main pike program running in the base directory and the include works there with #include "includes/kernel.h". I tried this with my login sequence file which is located at /lib/obj/std/login.pike but it says it can not find the file. And for future reference I am sure I will be sending out alot of questions. Thanks all in advance. > > >--------------------------------- >Do you Yahoo!? >Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes > > > / Brevb�raren > --------------------------------- Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes --------------------------------- Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes

1 0

OS X lock errors in testsuite
by Jonas Walld�n ＠ Pike developers forum 02 Jan '04

02 Jan '04

I noticed Grubba's comments in modules/files/testsuite.in and just want to add that the lock tests only fail on network volumes and only in 10.2 or earlier. When I run the testsuite in 10.3 it's ok. earl-grey was recently upgraded to 10.2 and gcc 3.3, and since I'm not sure how backwards compatibility for our (Roxen's) Pike binaries is affected by a 10.3 upgrade it will probably stay at 10.2 for the foreseeable future.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pike-devel January 2004