I'm having trouble getting py27-graph-tool installed.   I get:

$ cat 
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-graph-tool/py27-graph-tool/main.log
...
:info:build graph_eigentrust.cc:46:   instantiated from here
:info:build graph_eigentrust.hh:86: error: no match for 'operator[]'
in 
'c[((boost::iterator_facade<boost::transform_iterator<boost::detail::reverse_graph_edge_descriptor_maker<boost::detail::edge_desc_impl<boost::bidirectional_tag,
long unsigned int> >,
boost::filter_iterator<boost::detail::in_edge_predicate<graph_tool::detail::MaskFilter<boost::unchecked_vector_property_map<unsigned
char, boost::adj_list_edge_property_map<boost::bidirectional_tag, long
unsigned int, long unsigned int&, long unsigned int,
boost::property<boost::edge_index_t, long unsigned int,
boost::no_property>, boost::edge_index_t> > >,
graph_tool::detail::MaskFilter<boost::unchecked_vector_property_map<unsigned
char, boost::vec_adj_list_vertex_id_map<boost::no_property, long
unsigned int> > >,
boost::filtered_graph<boost::adjacency_list<boost::vecS, boost::vecS,
boost::bidirectionalS, boost::no_property,
boost::property<boost::edge_index_t, long unsigned int,
boost::no_property>, boost::no_property, boost::listS>,
graph_tool::detail::MaskFilter<boost::unchecked_vector_property_map<unsigned
char, boost::adj_list_edge_property_map<boost::bidirectional_tag, long
unsigned int, long unsigned int&, long unsigned int,
boost::property<boost::edge_index_t, long unsigned int,
boost::no_property>, boost::edge_index_t> > >,
graph_tool::detail::MaskFilter<boost::unchecked_vector_property_map<unsigned
char, boost::vec_adj_list_vertex_id_map<boost::no_property, long
unsigned int> > > > >,
boost::detail::in_edge_iter<__gnu_cxx::__normal_iterator<boost::detail::sei_<long
unsigned int, std::_List_iterator<boost::list_edge<long unsigned int,
boost::property<boost::edge_index_t, long unsigned int,
boost::no_property> > >, boost::property<boost::edge_index_t, long
unsigned int, boost::no_property> >*,
std::vector<boost::detail::sei_<long unsigned int,
std::_List_iterator<boost::list_edge<long unsigned int,
boost::property<boost::edge_index_t, long unsigned int,
boost::no_property> > >, boost::property<boost::edge_index_t, long
unsigned int, boost::no_property> >,
std::allocator<boost::detail::sei_<long unsigned int,
std::_List_iterator<boost::list_edge<long unsigned int,
boost::property<boost::edge_index_t, long unsigned int,
boost::no_property> > >, boost::property<boost::edge_index_t, long
unsigned int, boost::no_property> > > > >, long unsigned int,
boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned
int>, long int> >, boost::use_default, boost::use_default>,
boost::detail::reverse_graph_edge_descriptor<boost::detail::edge_desc_impl<boost::bidirectional_tag,
long unsigned int> >,
boost::detail::iterator_category_with_traversal<std::input_iterator_tag,
boost::bidirectional_traversal_tag>,
boost::detail::reverse_graph_edge_descriptor<boost::detail::edge_desc_impl<boost::bidirectional_tag,
long unsigned int> >, long int>*)(& e))->boost::iterator_facade<I, V,
TC, R, D>::operator* [with Derived =
boost::transform_iterator<boost::detail::reverse_graph_edge_descriptor_maker<boost::detail::edge_desc_impl<boost::bidirectional_tag,
long unsigned int> >,
boost::filter_iterator<boost::detail::in_edge_predicate<graph_tool::detail::MaskFilter<boost::unchecked_vector_property_map<unsigned
char, boost::adj_list_edge_property_map<boost::bidirectional_tag, long
unsigned int, long unsigned int&, long unsigned int,
boost::property<boost::edge_index_t, long unsigned int,
boost::no_property>, boost::edge_index_t> > >,
graph_tool::detail::MaskFilter<boost::unchecked_vector_property_map<unsigned
char, boost::vec_adj_list_vertex_id_map<boost::no_property, long
unsigned int> > >,
boost::filtered_graph<boost::adjacency_list<boost::vecS, boost::vecS,
boost::bidirectionalS, boost::no_property,
boost::property<boost::edge_index_t, long unsigned int,
boost::no_property>, boost::no_property, boost::listS>,
graph_tool::detail::MaskFilter<boost::unchecked_vector_property_map<unsigned
char, boost::adj_list_edge_property_map<boost::bidirectional_tag, long
unsigned int, long unsigned int&, long unsigned int,
boost::property<boost::edge_index_t, long unsigned int,
boost::no_property>, boost::edge_index_t> > >,
graph_tool::detail::MaskFilter<boost::unchecked_vector_property_map<unsigned
char, boost::vec_adj_list_vertex_id_map<boost::no_property, long
unsigned int> > > > >,
boost::detail::in_edge_iter<__gnu_cxx::__normal_iterator<boost::detail::sei_<long
unsigned int, std::_List_iterator<boost::list_edge<long unsigned int,
boost::property<boost::edge_index_t, long unsigned int,
boost::no_property> > >, boost::property<boost::edge_index_t, long
unsigned int, boost::no_property> >*,
std::vector<boost::detail::sei_<long unsigned int,
std::_List_iterator<boost::list_edge<long unsigned int,
boost::property<boost::edge_index_t, long unsigned int,
boost::no_property> > >, boost::property<boost::edge_index_t, long
unsigned int, boost::no_property> >,
std::allocator<boost::detail::sei_<long unsigned int,
std::_List_iterator<boost::list_edge<long unsigned int,
boost::property<boost::edge_index_t, long unsigned int,
boost::no_property> > >, boost::property<boost::edge_index_t, long
unsigned int, boost::no_property> > > > >, long unsigned int,
boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned
int>, long int> >, boost::use_default, boost::use_default>, Value =
boost::detail::reverse_graph_edge_descriptor<boost::detail::edge_desc_impl<boost::bidirectional_tag,
long unsigned int> >, CategoryOrTraversal =
boost::detail::iterator_category_with_traversal<std::input_iterator_tag,
boost::bidirectional_traversal_tag>, Reference =
boost::detail::reverse_graph_edge_descriptor<boost::detail::edge_desc_impl<boost::bidirectional_tag,
long unsigned int> >, Difference = long int]()]'
:info:build ./../fast_vector_property_map.hh:170: note: candidates
are: typename std::iterator_traits<typename std::vector<T,
std::allocator<_CharT> >::iterator>::reference
boost::unchecked_vector_property_map<T, IndexMap>::operator[](const
typename boost::property_traits<IndexMap>::key_type&) const [with T =
long double, IndexMap =
boost::adj_list_edge_property_map<boost::bidirectional_tag, long
unsigned int, long unsigned int&, long unsigned int,
boost::property<boost::edge_index_t, long unsigned int,
boost::no_property>, boost::edge_index_t>]
:info:build make[4]: *** [graph_eigentrust.lo] Error 1
:info:build make[4]: *** Waiting for unfinished jobs....
:info:build make[4]: *** [graph_betweenness.lo] Error 1
:info:build make[4]: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-graph-tool/py27-graph-tool/work/graph-tool-2.2.15/src/graph/centrality'
:info:build make[3]: *** [all-recursive] Error 1
:info:build make[3]: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-graph-tool/py27-graph-tool/work/graph-tool-2.2.15/src/graph'
:info:build make[2]: *** [all-recursive] Error 1
:info:build make[2]: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-graph-tool/py27-graph-tool/work/graph-tool-2.2.15/src'
:info:build make[1]: *** [all-recursive] Error 1
:info:build make[1]: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-graph-tool/py27-graph-tool/work/graph-tool-2.2.15'
:info:build make: *** [all] Error 2
:info:build make: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-graph-tool/py27-graph-tool/work/graph-tool-2.2.15'
:info:build shell command " cd
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-graph-tool/py27-graph-tool/work/graph-tool-2.2.15"
&& make -j2 -w all " returned error 2
:error:build Target org.macports.build returned: shell command failed
(see log for details)
:debug:build Backtrace: shell command failed (see log for details)
    while executing
"command_exec build"
    (procedure "portbuild::build_main" line 8)
    invoked from within
"$procedure $targetname"
:info:build Warning: the following items did not execute (for
py27-graph-tool): org.macports.activate org.macports.build
org.macports.destroot org.macports.install
:notice:build Log for py27-graph-tool is at:
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-graph-tool/py27-graph-tool/main.log

Any solutions?


On Wed, Mar 14, 2012 at 7:00 AM,
<[email protected]> wrote:
> Send macports-users mailing list submissions to
>        [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
> or, via email, send a message with subject or body 'help' to
>        [email protected]
>
> You can reach the person managing the list at
>        [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of macports-users digest..."
>
>
> Today's Topics:
>
>   1. Re: gnuplot: question about wxWidgets(-devel)&  Universal
>      variants (Jonathan Stickel)
>   2. Re: gnuplot: question about wxWidgets(-devel)& Universal
>      variants (Mojca Miklavec)
>   3. Re: gnuplot: question about wxWidgets(-devel)& Universal
>      variants (Jonathan Stickel)
>   4. Linux equivalent libraries on macports (anupash)
>   5. run a tcp server to listen to a port range (michael sparacio)
>   6. Re: Linux equivalent libraries on macports (Ryan Schmidt)
>   7. Re: run a tcp server to listen to a port range (Ryan Schmidt)
>   8. ticket 33570 (Zhong Ren)
>   9. Re: run a tcp server to listen to a port range (michael sparacio)
>  10. Re: run a tcp server to listen to a port range (Ryan Schmidt)
>  11. Re: run a tcp server to listen to a port range (Jan Stary)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 13 Mar 2012 08:24:17 -0600
> From: Jonathan Stickel <[email protected]>
> To: [email protected]
> Subject: Re: gnuplot: question about wxWidgets(-devel)&  Universal
>        variants
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 3/13/12 08:00 , [email protected] wrote:
>> Subject: Re: gnuplot: question about wxWidgets(-devel)&  Universal
>> variants
>>
>> On Mon, Mar 12, 2012 at 01:46, Ryan Schmidt wrote:
>>>>
>>>>>> How exactly should the code be written to enable compiling
>>>>>> 64-bit version of gnuplot with wxt terminal, without
>>>>>> interfering with other ports and without breaking
>>>>>> functionality for 32-bit architectures? Once/if that question
>>>>>> is answered, I have a Portfile for the new gnuplot 4.6 ready
>>>>>> to be committed.
>>>>
>>>> The simplest solution for us would be for the developers of
>>>> wxWidgets to finally release a stable 64-bit compatible version
>>>> of their software. Then we could update the wxWidgets portfile to
>>>> that version and remove all the 32-bit forcing in all the ports
>>>> that do that.
>> However that probably won't happen for some time.
>>
>> Would it be acceptable for a non-default option of gnuplot to simply
>> depend on wxWidgets-devel then? The version 2.9 also contains some
>> nice features that are missing in 2.8, so it's not just about type
>> of binary. (If necessary, there could be two options, one with
>> wxWidgets and one with wxWidgets-devel, but I don't really think that
>> two options are needed.)
>>
>> I tried to create an update at
>> https://trac.macports.org/ticket/33596
>>
>
> wxWidgets and 64-bit has been a real PITA for some time now.  The
> development series 2.9 has promise, but there are some problems.  If you
> really need wxWidgets, I suggest using the X11/gtk backend.  See this
> old ticket for a full explanation:
>
> http://trac.macports.org/ticket/24350
>
> The variant for the 64-bit capable X11/gtk backend is available in the
> wxwidgets-python port.  This could be translated to the regular
> wxwidgets port if someone is interested.  I have stopped using wxwidgets
> due to these problems and am now using qt4.
>
> Jonathan
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 13 Mar 2012 15:57:20 +0100
> From: Mojca Miklavec <[email protected]>
> To: MacPorts Users Mailing-list <[email protected]>
> Cc: Jonathan Stickel <[email protected]>
> Subject: Re: gnuplot: question about wxWidgets(-devel)& Universal
>        variants
> Message-ID:
>        <calbomsyfyjksgyujjd8snahq7e3rvhgj52zqbyxuodwe4g0...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Tue, Mar 13, 2012 at 15:24, Jonathan Stickel wrote:
>>
>> wxWidgets and 64-bit has been a real PITA for some time now.?The
>> development series 2.9 has promise, but there are some problems.
>
> I would have asked "what kind of problems", but I don't want to open a
> can of worms ;)
>
> At least it works for me for using a Gnuplot terminal. The old version
> (2.8) also works of course, but only for 32-bit applications and it
> lacks two nice features which is a bit painful.
>
>>?If you
>> really need wxWidgets, I suggest using the X11/gtk backend. ?See this old
>> ticket for a full explanation:
>
> I have no idea how to use X11/gtk backend, and since wxWidgets-devel
> also work (with Cocoa interface), I see no reason for including yet
> another alien into the game. But if that would simplify macports
> packaging and if somebody can show me how to do it, I have nothing
> against a working solution. I don't particularly like X11 thouh and
> there is already an X11 terminal available (with slightly less
> features), but if that's what it takes ...
>
>> http://trac.macports.org/ticket/24350
>
> I'm not sure that I understand all of what is written here.
>
>> The variant for the 64-bit capable X11/gtk backend is available in the
>> wxwidgets-python port. ?This could be translated to the regular wxwidgets
>> port if someone is interested. ?I have stopped using wxwidgets due to these
>> problems and am now using qt4.
>
> I would never develop a wxWidgets application myself, and even the
> author of wxWidgets code for gnuplot says that he is no longer
> interested in further maintainance (and that he would have written Qt
> code back then if he knew what he knows now). But since the code is
> there and application works now, it would be nice to support it as
> long as supporting is not too painful. The Portfile that I wrote
> (https://trac.macports.org/ticket/33596) seems to work, its only
> drawback is dependency on wxWidgets-devel and I'm not sure how that
> works on older macs.
>
> Gnuplot now also supports Qt terminal (which is not really polished
> out yet, at least not for the mac; printing semi-crashes,
> configuration is suboptimal and doesn't work out of the box), so Qt
> terminal is definitely an alternative. It would help if some
> knowledgable developer would fix a few mac-specific problems in
> gnuplot source code though (I can describe problems, but don't know
> how to solve them properly).
>
> I wouldn't have used MacPorts' gnuplot at all, but I don't know any
> other way if I want to use Octave. And AquaTerm is causing me serious
> problems (= it doesn't work at all), so I need at least one working
> terminal that's different from AquaTerm and both Qt and wxWidgets are
> good candidates that finally happen to work on mac in gnuplot 4.6.
>
> Mojca
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 13 Mar 2012 09:25:24 -0600
> From: Jonathan Stickel <[email protected]>
> To: Mojca Miklavec <[email protected]>
> Cc: MacPorts Users Mailing-list <[email protected]>
> Subject: Re: gnuplot: question about wxWidgets(-devel)& Universal
>        variants
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
>
> On 3/13/12 08:57 , Mojca Miklavec wrote:
>> On Tue, Mar 13, 2012 at 15:24, Jonathan Stickel wrote:
>>>
>>> wxWidgets and 64-bit has been a real PITA for some time now. The
>>> development series 2.9 has promise, but there are some problems.
>>
>> I would have asked "what kind of problems", but I don't want to open a
>> can of worms ;)
>
> I have found that it is not compatible with Mayavi (a python
> visualization program), and I suspect the same for other projects that
> use wxwidgets.
>
>>
>> At least it works for me for using a Gnuplot terminal. The old version
>> (2.8) also works of course, but only for 32-bit applications and it
>> lacks two nice features which is a bit painful.
>>
>
> If it works for you, great!
>
>>>   If you
>>> really need wxWidgets, I suggest using the X11/gtk backend.  See this old
>>> ticket for a full explanation:
>>
>> I have no idea how to use X11/gtk backend, and since wxWidgets-devel
>> also work (with Cocoa interface), I see no reason for including yet
>> another alien into the game. But if that would simplify macports
>> packaging and if somebody can show me how to do it, I have nothing
>> against a working solution. I don't particularly like X11 thouh and
>> there is already an X11 terminal available (with slightly less
>> features), but if that's what it takes ...
>>
>
> Everything needed for the variant should be in the "wxwidgets-python"
> portfile.  A simple copy of the relevant lines to the wxwidgets portfile
> should work OK.  Some bug-squashing might be needed.  But if
> wxwidgets-2.9 works for gnuplot, that does seem like a better solution
> than X11/gtk.
>
>>> http://trac.macports.org/ticket/24350
>>
>> I'm not sure that I understand all of what is written here.
>>
>>> The variant for the 64-bit capable X11/gtk backend is available in the
>>> wxwidgets-python port.  This could be translated to the regular wxwidgets
>>> port if someone is interested.  I have stopped using wxwidgets due to these
>>> problems and am now using qt4.
>>
>> I would never develop a wxWidgets application myself, and even the
>> author of wxWidgets code for gnuplot says that he is no longer
>> interested in further maintainance (and that he would have written Qt
>> code back then if he knew what he knows now). But since the code is
>> there and application works now, it would be nice to support it as
>> long as supporting is not too painful. The Portfile that I wrote
>> (https://trac.macports.org/ticket/33596) seems to work, its only
>> drawback is dependency on wxWidgets-devel and I'm not sure how that
>> works on older macs.
>>
>> Gnuplot now also supports Qt terminal (which is not really polished
>> out yet, at least not for the mac; printing semi-crashes,
>> configuration is suboptimal and doesn't work out of the box), so Qt
>> terminal is definitely an alternative. It would help if some
>> knowledgable developer would fix a few mac-specific problems in
>> gnuplot source code though (I can describe problems, but don't know
>> how to solve them properly).
>>
>> I wouldn't have used MacPorts' gnuplot at all, but I don't know any
>> other way if I want to use Octave. And AquaTerm is causing me serious
>> problems (= it doesn't work at all), so I need at least one working
>> terminal that's different from AquaTerm and both Qt and wxWidgets are
>> good candidates that finally happen to work on mac in gnuplot 4.6.
>>
>
> I am facing similar problems with wx vs qt backends for matplotlib and
> mayavi in python.  wx used to be the standard backend, but is being
> phased out (I think partly because of this painful transition from 2.8
> to 2.9).  Qt4 is the new preferred backend, but not all features work
> correctly.  This has been an issue for over 2 years now.  Hopefully
> things will get better over time.  I have decided to got the Qt4 route
> and am dealing with the few issues.
>
> Jonathan
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 13 Mar 2012 11:57:19 -0700 (PDT)
> From: anupash <[email protected]>
> To: [email protected]
> Subject: Linux equivalent libraries on macports
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
>
> Hi,
>
> I am a new user and running Mac OS X Lion. I have set up macports used it to
> install a variety of packages. However I have to install few packages which
> I need to compile my thesis code. The equivalent dependencies for linux
> (Ubuntu) are autoconf automake libtool make gcc libssl-dev iptables-dev
> libconfig8-dev libnet-ip-perl libnet-dns-perl
>
> I was able to find out the macports equivalent for most of them but not for
> iptables-dev. I know it is a very linux specific dependency but still is
> there a way to get it?
>
> Pardon me if this is double posted as new posts require me to register to
> mailing list and hence my previous post was automatically rejected
> --
> View this message in context: 
> http://old.nabble.com/Linux-equivalent-libraries-on-macports-tp33496803p33496803.html
> Sent from the MacPorts - Users mailing list archive at Nabble.com.
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 13 Mar 2012 17:10:28 -0400
> From: michael sparacio <[email protected]>
> To: [email protected]
> Subject: run a tcp server to listen to a port range
> Message-ID: <[email protected]>
> Content-Type: text/plain; CHARSET=US-ASCII
>
> Is there a recommended port that will listen to a range of tcp ports? I am 
> playing with netcat but it seems it can only listen to a single port at a 
> time. I'd like to open hundreds or even thousands of tcp ports for firewall 
> screens testing.
>
> Thanks,
> -ms
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 13 Mar 2012 16:11:20 -0500
> From: Ryan Schmidt <[email protected]>
> To: anupash <[email protected]>
> Cc: [email protected]
> Subject: Re: Linux equivalent libraries on macports
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
> On Mar 13, 2012, at 13:57, anupash wrote:
>
>> I am a new user and running Mac OS X Lion. I have set up macports used it to
>> install a variety of packages. However I have to install few packages which
>> I need to compile my thesis code. The equivalent dependencies for linux
>> (Ubuntu) are autoconf automake libtool make gcc libssl-dev iptables-dev
>> libconfig8-dev libnet-ip-perl libnet-dns-perl
>>
>> I was able to find out the macports equivalent for most of them but not for
>> iptables-dev. I know it is a very linux specific dependency but still is
>> there a way to get it?
>
> iptables is for Linux only:
>
> http://en.wikipedia.org/wiki/Iptables
>
> It is a program used to configure the Linux firewall; the Linux firewall is 
> not available on OSX.
>
> For similar functionality on OSX Snow Leopard and earlier, look into ipfw 
> instead:
>
> http://en.wikipedia.org/wiki/Ipfw
>
> On OSX Lion and later, ipfw is deprecated and replaced by PF:
>
> http://en.wikipedia.org/wiki/PF_(firewall)
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 13 Mar 2012 16:12:40 -0500
> From: Ryan Schmidt <[email protected]>
> To: michael sparacio <[email protected]>
> Cc: [email protected]
> Subject: Re: run a tcp server to listen to a port range
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Mar 13, 2012, at 16:10, michael sparacio wrote:
>
>> Is there a recommended port that will listen to a range of tcp ports? I am 
>> playing with netcat but it seems it can only listen to a single port at a 
>> time. I'd like to open hundreds or even thousands of tcp ports for firewall 
>> screens testing.
>
> nodejs is JavaScript environment with which it's very easy to create network 
> servers that do whatever you want them to. Perhaps that will help you.
>
> http://nodejs.org/
>
> Yes, you can install nodejs with MacPorts.
>
> sudo port install nodejs
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 13 Mar 2012 16:48:07 -0500 (CDT)
> From: Zhong Ren <[email protected]>
> To: "Ryan Schmidt" <[email protected]>
> Cc: [email protected]
> Subject: ticket 33570
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
> Could someone look at this ticket please:
>
> <https://trac.macports.org/ticket/33570#comment:2>
>
> Zhong
>
>
>
> ------------------------------
>
> Message: 9
> Date: Tue, 13 Mar 2012 22:42:54 -0400
> From: michael sparacio <[email protected]>
> To: Ryan Schmidt <[email protected]>
> Cc: [email protected]
> Subject: Re: run a tcp server to listen to a port range
> Message-ID: <[email protected]>
> Content-Type: text/plain; CHARSET=US-ASCII
>
> I am not familiar with js but trying to get an example.js coded properly, 
> this is only listening on the final port, the 10100...
>
> var net = require('net');
> var port = 10000
> for (port = 10000; port < 10100; port++) {
>  ;
> }
> var server = net.createServer(function(c) { //'connection' listener
>  console.log('server connected');
>  c.on('end', function() {
>    console.log('server disconnected');
>  });
>  c.write('hello\r\n');
>  c.pipe(c);
> });
> server.listen(port, function() { //'listening' listener
>  console.log('server bound');
> });
>
> I assume I am making a dumb error??
>
> thanks for any suggestions.
>
> -ms
>
>
> On Mar 13, 2012, at 5:12 PM, Ryan Schmidt wrote:
>
>>
>> On Mar 13, 2012, at 16:10, michael sparacio wrote:
>>
>>> Is there a recommended port that will listen to a range of tcp ports? I am 
>>> playing with netcat but it seems it can only listen to a single port at a 
>>> time. I'd like to open hundreds or even thousands of tcp ports for firewall 
>>> screens testing.
>>
>> nodejs is JavaScript environment with which it's very easy to create network 
>> servers that do whatever you want them to. Perhaps that will help you.
>>
>> http://nodejs.org/
>>
>> Yes, you can install nodejs with MacPorts.
>>
>> sudo port install nodejs
>>
>>
>
>
>
> ------------------------------
>
> Message: 10
> Date: Wed, 14 Mar 2012 00:53:18 -0500
> From: Ryan Schmidt <[email protected]>
> To: michael sparacio <[email protected]>
> Cc: [email protected]
> Subject: Re: run a tcp server to listen to a port range
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Mar 13, 2012, at 21:42, michael sparacio wrote:
>
>> I am not familiar with js but trying to get an example.js coded properly, 
>> this is only listening on the final port, the 10100...
>>
>> var net = require('net');
>> var port = 10000
>> for (port = 10000; port < 10100; port++) {
>>  ;
>> }
>> var server = net.createServer(function(c) { //'connection' listener
>>  console.log('server connected');
>>  c.on('end', function() {
>>    console.log('server disconnected');
>>  });
>>  c.write('hello\r\n');
>>  c.pipe(c);
>> });
>> server.listen(port, function() { //'listening' listener
>>  console.log('server bound');
>> });
>>
>> I assume I am making a dumb error??
>
> Your program initializes a variable "port" to the value 10000, then 
> increments it until it reaches 10100. It then creates a server and assigns it 
> to the variable "server", then tells the server to listen on that port. If 
> you want to create multiple servers that each listen on a different port, 
> you'll want to create the servers inside the loop.
>
> But we are veering off-topic here. The MacPorts mailing lists are not well 
> suited to discussing JavaScript programming. If you have further questions 
> that aren't answered by reading the nodejs documentation and sample programs, 
> you should ask on the nodejs mailing list:
>
> http://groups.google.com/group/nodejs
>
>
>
>
> ------------------------------
>
> Message: 11
> Date: Wed, 14 Mar 2012 08:30:09 +0100
> From: Jan Stary <[email protected]>
> To: [email protected]
> Subject: Re: run a tcp server to listen to a port range
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
> On Mar 13 17:10:28, michael sparacio wrote:
>> Is there a recommended port that will listen to a range of tcp ports? I am 
>> playing with netcat but it seems it can only listen to a single port at a 
>> time. I'd like to open hundreds or even thousands of tcp ports for firewall 
>> screens testing.
>
> Run a thousand netcats.
>
>
>
> ------------------------------
>
> _______________________________________________
> macports-users mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
>
>
> End of macports-users Digest, Vol 67, Issue 14
> **********************************************
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Reply via email to