Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

Culture Surprises in Remote Software Development Teams
by Martin Bähr 30 Jan '04

30 Jan '04

hi, i found this interresting article, which as it touches on our situation, i think is worth reading. Culture Surprises in Remote Software Development Teams http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=105 Technology has made it possible for organizations to construct teams of people who are not in the same location, adopting what one company calls "virtual collocation." Worldwide groups of software developers, financial analysts, automobile designers, consultants, pricing analysts, and researchers are examples of teams that work together from disparate locations, using a variety of collaboration technologies that allow communication across space and time. Although solving the problems of space and time is difficult, these are not the only issues. Work that takes place over long distances means that communication will often involve different cultures. Participants may be surprised by such interactions because they have not considered various cultural differences and how they impact the daily work of long-distance teams. Our own culture is invisible to us. "We don't see our own ways of doing things as conditioned in the cradle," writes Esther Wanning, author of Culture Shock! USA. "We see them as correct, and we conclude that people from other countries have grave failings." The goal of this article is to review various cultural differences likely to appear in the work setting and explore their implications for virtual collocation of software development teams. We begin with a definition of culture and various dimensions of cultural difference that have emerged. Then we examine two cases: (1) one in which the team members are collocated; and (2) one involving the team in virtual collocation. From this analysis we draw some practical implications. greetings, martin.

1 0

Re: Pike @ Debian
by David Hedbor ＠ Pike developers forum 29 Jan '04

29 Jan '04

The one and only way to compile Pike modules that should be endorsed and/or developed is "pike -x module". That's it. If it doesn't work it. If it requires the entirety of Pike, deal with it. That's about all I have to say. / David Hedbor Previous text: >2004-01-26 21:32: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 08:55:02PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled: >> _No_. It can _not_ be tailored to the distribution, because then the >> Pike modules you distribute could only be compiled with that >> distrubution. That would be totally useless. >Huh? pike.m4's purpose is would be to: > > a) detect the presence of the Pike binaries on the system (or requested > components thereof) > > b) inform the application where the .h, .pmod etc. etc. files are located. > >How could that prevent the code from being compiled on different operating >systems??? Since when the contents of the information above matters and not >the way you get the information? If you have 10 OSes and each of them keeps >the .h files in a different location, but you have one pike.m4 which has a >macro > > PIKE_C_HEADER_FILES > >which sets the PIKE_HEADERS variable to the location of the .h files on the >system, then where is the problem? > >You put > >CC_INCLUDES=$(PIKE_HEADERS) > >in your makefile and your code perfectly compiles on any OS, no matter where >it keeps the files. Suspecting that you might have misunderstood the >'tailoring' part - I meant by it that the maintainer of the Pike port for a >particular system can modify it and customize for his platform. I didn't >mean it has to be done in the Pike core, all gods of the universe forbid! As >said previously somewhere, the .m4 could just source a config file put in a >well-known location. That would make it extremely configurable and flexible, >not to mention simple. > >marek > > > > > / Brevbäraren >

6 7

Re: sslfile
by Martin Nilsson (saturator) ＠ Pike (-) developers forum 28 Jan '04

28 Jan '04

query_fd previously returned -1. / Martin Nilsson (saturator) Previous text: >2004-01-28 19:35: >Subject: Re: sslfile >-------------------------------------------------------------------- >What methods, specifically? I know that die() is one of them... > >Bill > >On Wednesday, January 28, 2004, at 12:30 PM, Martin Nilsson (saturator) >@ Pike (-) developers forum wrote: > >> After the rewrite of SSL.sslfile some methods available before are >> gone. >> Is that a mistake in terms of removal or in terms of not adding >> compatibility? > > > > / Brevbäraren >

1 0

sslfile
by Martin Nilsson (saturator) ＠ Pike (-) developers forum 28 Jan '04

28 Jan '04

After the rewrite of SSL.sslfile some methods available before are gone. Is that a mistake in terms of removal or in terms of not adding compatibility?

1 0

win32 builds
by Peter Bortas ＠ Pike developers forum 28 Jan '04

28 Jan '04

If someone feel they don't have enough exitement in their lives feel free to test <URL:http://peter.bortas.org/pikedev/Pike-7.4.35beta-win32-bhelliom.exe> or <URL:http://peter.bortas.org/pikedev/Pike-7.5.17alpha-win32-bhelliom.exe> They are totally untested and only intended for testing some changes to the installation package: * ICON rescource in pike.exe * New installer icon * Added possibility to use 10 instead on 1 argument to pike.exe on the command line. * Fixed up my win32 compileation environment again. Observe: I haven't even tried to run these executables since my win32 testing system is currently spread all over my workbench. Feel free to report back if it does work though.

3 17

Re: Pike @ Debian
by Johan Sundstr�m (Achtung Liebe!) ＠ Pike (-) developers forum 27 Jan '04

27 Jan '04

Hm. Marek, if I just made an ass of myself by assuming you just took some quarantine time off the list, and thus incorrectly addressed you in third person like this, I'm sorry. (For which I whole-heartedly put all blame on Embee's sudden recurring diversion tactics, in a not very successful effort at humour on my part. Got to practice some more. :-)

3 3

Re: Pike @ Debian
by Per Hedbor () ＠ Pike (-) developers forum 27 Jan '04

27 Jan '04

Then they simply won't work in Pike 7.5. If you had used pike -x module you would have got the .pmod files for free. / Per Hedbor () Previous text: >2004-01-26 21:41: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 09:35:07PM +0100, Per Hedbor () @ Pike (-) developers forum scribbled: >> Even pure C-modules generate .pmod files nowdays. Which is what I >> wrote, I think. >None of the pexts, caudium or php4 modules do. What's your point? > >marek > > > > / Brevbäraren >

2 1

Re: Pike @ Debian
by Per Hedbor () ＠ Pike (-) developers forum 27 Jan '04

27 Jan '04

No, we do not ignore external modules. But the current aclocal.m4 does not have anything to do with what you want (pike.m4 for automake/aclocal). Thus it's not sensible to 'clean it up' and install it as such. Writing a pike.m4 would, however, make sense. / Per Hedbor () Previous text: >2004-01-26 22:18: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 09:45:04PM +0100, Niels Möller (vässar rödpennan) @ Pike (-) developers forum scribbled: >> >Alas, it wouldn't... If some Pike C module runs aclocal it could pull in >> >both the pike's aclocal.m4 and other files with, possibly, macros that are >> >already defined in the pike's aclocal.m4 file. I doubt autoconf is smart >> >enough to cope with it ;) >> >> I think you're confusing several things here. Autoconf, automake, the >> aclocal program (more or less a part of automake), and the aclocal.m4 >> file are not all used together and are not using the same conventions. >Believe or not, but I'm quite aware of that. Let me remind you that the >proposition was to put the pike's aclocal.m4 under a different name in the >system-wide .m4 directory. Does that change your assessment? > >> aclocal.m4 existed long before automake, and it plays the same role >> that acinclude.m4 plays in automakeified projects. It's a >> *handwritten* file included by autoconf, specific to the project being >> built. >Again, I'm quite aware of the fact. > >> The aclocal proram is a later invention that constructs an aclocal.m4 >> file from various fragments stored somewhere under share. >You haven't surprised me here, either. > >> Pike uses autoconf, and uses aclocal.m4 the the way it was intended >> when autoconf was first written. It does *not* use automake, and it >> does *not* use the aclocal program. It's aclocal.m4 is *not* intended >> to ever be picked up by the aclocal program. >It does *not* mean the external Pike modules written in C _cannot_ use >automake, am I right? Or is it forbidden because Pike itself doesn't use it? > >> So the main poitn here is that any debian policy that has to do with >> automake and the aclocal program is totally irrelevant to pike. >Of course it isn't. But it might be relevant to external Pike modules. But >you're determined to ignore them, right? > >marek > > > > / Brevbäraren >

6 7

Re: pike -x testing
by Martin Nilsson (saturator) ＠ Pike (-) developers forum 27 Jan '04

27 Jan '04

[nilsson@mahoro 7.5]$ pike --version Pike v7.5 release 17 Copyright © 1994-2004 Linköping University Pike comes with ABSOLUTELY NO WARRANTY; This is free software and you are welcome to redistribute it under certain conditions; Read the files COPYING and COPYRIGHT in the Pike distribution for more details. [nilsson@mahoro 7.5]$ pike -x Pike -x specificed without tool name. Available tools: assemble_autodoc Assembles AutoDoc output file. benchmark Runs some built in Pike benchmarks. cgrep Context aware grep. dump Dumps pike files into object files. extract_autodoc Extracts autodoc from Pike or C code. extract_locale Pike locale extractor utility hilfe Hubbes Interactive LPC FrontEnd. join_autodoc Joins AutoDoc extractions. module Pike module installer. pv Pike image viewer (diet). rsif Replaces strings in files. rsqld Implements an rsql daemon. I don't remember when it was added. Perhaps a year ago. / Martin Nilsson (saturator) Previous text: >2004-01-27 11:58: >Subject: Re: pike -x testing >-------------------------------------------------------------------- >[...] > >> I'd like to see >> >> $ pike -x >> Pike: You must provide the name of a tool. Available tools: >> >> module Build a standalone pike module. >> pv Image viewer >> bench Pike benchmark >> >> It would be nice to have the testsuite exersize all supported tools, >> and have pike -x testsuite run the testsuite. > >This should be a really good idea ! > >/Xavier > > > > / Brevbäraren >

1 0

Pike7.5-20040126-234515 snapshot(s?) "make install" porblems
by Alexander Demenshin 27 Jan '04

27 Jan '04

Hi, Again tried to compile and install (latest snapshot), verify was ok, but on install it looped at: if [ -f dumpversion ]; then make delete_dumped_modules; else :; fi /home/aldem/src/Pike7.5-20040126-234515/src/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/home/aldem/src/Pike7.5-20040126-234515/src/master.pike -x extract_autodoc -q --srcdir=/home/aldem/src/Pike7.5-20040126-234515/src \ --imgsrc=/home/aldem/src/Pike7.5-20040126-234515/refdoc/src_images --builddir=doc_build/src \ --imgdir=doc_build/images make: *** [autodoc.xml] Interrupt So I had to stop it (after ca. 10 minutes). The result: a _lot_ of recursively created dirs under doc_build/src. The result of strace (during execcution of this phase) was like: lstat64("/home/aldem/src/Pike7.5-20040126-234515/src/doc_build/src/doc_build/src/doc_build/.../src/tlib/modules/Languages.pmod", {st_mode=S_IFDIR|0755, st_size=48, ...}) = 0 "..." is a repetition of "doc_build/src" many times. Something is definitely wrong in install process... Is there a target to install _without_ any docs/images etc? Regards, /Al

3 5

Jump to page:

2025

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