On 05/14/2014 06:41 PM, Wyatt wrote:
>
>> To me, shared is a type modifier that doesn't implicitely convert to
>> anything else without casting.
>
> Interesting, maybe this should be clarified better.  Having skimmed back
> over chapter 13 of TDPL, my understanding of its semantics are that it
> only really enforces atomicity and execution order.  Also, this bit from
> near the beginning of 13.12 states:
> "For all numeric types and function pointers, shared-qualified values
> are convertible implicitly to and from unqualified values."
>
> That sounds kind of at-odds with your interpretation...? :/

Not too much. Those are trivial cases (one copies the entire qualified data, so obviously one is free to change qualifiers as one wishes).

14-May-2014 17:16, Dicebot пишет:
> On Tuesday, 13 May 2014 at 21:16:55 UTC, Timon Gehr wrote:
>> On 05/13/2014 09:07 PM, Jacob Carlborg wrote:
>>> On 2014-05-13 15:56, Dicebot wrote:
>>>
>>>> Judging by http://static.rust-lang.org/doc/0.6/tutorial-macros.html
>>>> those are not full-blown AST macros like ones you have been proposing,
>>>> more like hygienic version of C macros.
>>>
>>> Hmm, I haven't looked at Rust macros that much.
>>>
>>
>> Again, the following is an example of Rust macros in action. A bf
>> program is compiled to Rust code at compile time.
>>
>> https://github.com/huonw/brainfuck_macro/blob/master/lib.rs
>>
>> Compile-time computations create an AST which is then spliced. Seems
>> full-blown enough to me and not at all like C macros.
>
> Comments look promising but unfortunately I can't understand a single
> line of actual code :) Mine rust-fu is too weak.

This is curious:
http://burntsushi.net/rustdoc/regex/

-- 
Dmitry Olshansky

On 14/05/14 23:47, Dmitry Olshansky wrote:

> This is curious:
> http://burntsushi.net/rustdoc/regex/

It seems they have compile time regular expressions too.

-- 
/Jacob Carlborg

On Thursday, 15 May 2014 at 06:30:40 UTC, Jacob Carlborg wrote:
> On 14/05/14 23:47, Dmitry Olshansky wrote:
>
>> This is curious:
>> http://burntsushi.net/rustdoc/regex/
>
> It seems they have compile time regular expressions too.

Yeah looks like my knowledge about their macro system is very outdated. Looks promising.

On 14.05.2014 12:56, "Marc Schütz" <schuetzm@gmx.net>" wrote:
> On Tuesday, 13 May 2014 at 19:50:52 UTC, Rainer Schuetze wrote:
>> class C { C next; }
>>
>> shared(C) list;
>>
>> C newC()
>> {
>>     return new C; // allocated on the local heap?
>
> Yes, because it doesn't say "new shared(C)".
>
>> }
>>
>> void prependToList(C c)
>> {
>>     synchronized(list)
>>     {
>>         C lst = cast(C) list;
>>         c.next = lst;  // anything special happening here?
>>         list = cast(shared(C)) c;  // and here?
>
> The casts are a problem. You're basically lying to the compiler, so this
> cannot work. Instead, it should be something like:
>
>      auto newC() {
>          return new isolated(C);
>      }
>
>      void prependToList(isolated(C) c) {
>          synchronized(list) {
>              // transfer to shared heap
>              // afterwards, c is no longer usable ("consumed")
>              shared(C) tmp = c.makeShared();
>              tmp.next = list;
>              list = tmp;
>          }
>      }


Sorry for the late reply.

I currently don't know of a feasible way to replace casting away "shared" if you want to do more than just "tmp.next = list;", for example call "bool check(C c);" on tmp or list? I can't implement this with a shared object, because any operations on "shared" tend to not exist (ok, maybe I could for this very simple example, so consider C contains a container to operate on). Also, the object is already locked, I should not have to do it again in a function if it only accepts a shared C.

How can I prepend something to the list that is not isolated? I guess I cannot, as it might create references to same object both shared and unshared.

My gut feeling tells me that this ownership handling through the type system might work, but it is very restrictive and does not really contribute to the first goal of D listed on the front page: "convenience".


>
> This uses the "isolated" concept suggested by deadalnix here:
> http://forum.dlang.org/thread/yiwcgyfzfbkzcavuqdwz@forum.dlang.org?page=1
>
>>     }
>> }
>>
>> void callMeFromMultipleThreads()
>> {
>>     prependToList(newC());
>> }
>

On Friday, 16 May 2014 at 16:58:38 UTC, Rainer Schuetze wrote:
>
>
> On 14.05.2014 12:56, "Marc Schütz" <schuetzm@gmx.net>" wrote:
>> On Tuesday, 13 May 2014 at 19:50:52 UTC, Rainer Schuetze wrote:
>>> class C { C next; }
>>>
>>> shared(C) list;
>>>
>>> C newC()
>>> {
>>>    return new C; // allocated on the local heap?
>>
>> Yes, because it doesn't say "new shared(C)".
>>
>>> }
>>>
>>> void prependToList(C c)
>>> {
>>>    synchronized(list)
>>>    {
>>>        C lst = cast(C) list;
>>>        c.next = lst;  // anything special happening here?
>>>        list = cast(shared(C)) c;  // and here?
>>
>> The casts are a problem. You're basically lying to the compiler, so this
>> cannot work. Instead, it should be something like:
>>
>>     auto newC() {
>>         return new isolated(C);
>>     }
>>
>>     void prependToList(isolated(C) c) {
>>         synchronized(list) {
>>             // transfer to shared heap
>>             // afterwards, c is no longer usable ("consumed")
>>             shared(C) tmp = c.makeShared();
>>             tmp.next = list;
>>             list = tmp;
>>         }
>>     }
>
>
> Sorry for the late reply.
>
> I currently don't know of a feasible way to replace casting away "shared" if you want to do more than just "tmp.next = list;", for example call "bool check(C c);" on tmp or list? I can't implement this with a shared object, because any operations on "shared" tend to not exist (ok, maybe I could for this very simple example, so consider C contains a container to operate on). Also, the object is already locked, I should not have to do it again in a function if it only accepts a shared C.
>
> How can I prepend something to the list that is not isolated? I guess I cannot, as it might create references to same object both shared and unshared.
>
> My gut feeling tells me that this ownership handling through the type system might work, but it is very restrictive and does not really contribute to the first goal of D listed on the front page: "convenience".

I haven't thought it through completely, of course, but I believe it doesn't have to be inconvenient. Maybe there is a nice solution. I already have something in mind, but I have to think it over first.

Rainer Schuetze <r.sagitario@gmx.de> writes:

> On 14.05.2014 12:56, "Marc Schütz" <schuetzm@gmx.net>" wrote:
>> On Tuesday, 13 May 2014 at 19:50:52 UTC, Rainer Schuetze wrote:
>>> class C { C next; }
>>>
>>> shared(C) list;
>>>
>>> C newC()
>>> {
>>>     return new C; // allocated on the local heap?
>>
>> Yes, because it doesn't say "new shared(C)".
>>
>>> }
>>>
>>> void prependToList(C c)
>>> {
>>>     synchronized(list)
>>>     {
>>>         C lst = cast(C) list;
>>>         c.next = lst;  // anything special happening here?
>>>         list = cast(shared(C)) c;  // and here?
>>
>> The casts are a problem. You're basically lying to the compiler, so this cannot work. Instead, it should be something like:
>>
>>      auto newC() {
>>          return new isolated(C);
>>      }
>>
>>      void prependToList(isolated(C) c) {
>>          synchronized(list) {
>>              // transfer to shared heap
>>              // afterwards, c is no longer usable ("consumed")
>>              shared(C) tmp = c.makeShared();
>>              tmp.next = list;
>>              list = tmp;
>>          }
>>      }
>
>
> Sorry for the late reply.
>
> I currently don't know of a feasible way to replace casting away "shared" if
> you want to do more than just "tmp.next = list;", for example call "bool
> check(C c);" on tmp or list? I can't implement this with a shared object,
> because any operations on "shared" tend to not exist (ok, maybe I could for
> this very simple example, so consider C contains a container to operate
> on). Also, the object is already locked, I should not have to do it again in a
> function if it only accepts a shared C.
>
> How can I prepend something to the list that is not isolated? I guess I cannot, as it might create references to same object both shared and unshared.
>
> My gut feeling tells me that this ownership handling through the type system might work, but it is very restrictive and does not really contribute to the first goal of D listed on the front page: "convenience".

Reading this, I had a thought.  What if synchronized temporarily stripped the shared qualifier from list?  At the end of the synchronized block, shared is restored.  Then:

void prependToList(C c) {
    synchronized(list) {       // list is now C, not shared(C)
        c.next = list;         // ok
        list = c;              // ok
        check(list);           // ok, not a shared object here
    }
    // list is now shared again.  move list to shared heap if not already
}

I'm sure I'm missing something, but using shared within a synchronized block might be saner if this worked...

Jerry

On Wednesday, 28 November 2018 at 09:16:14 UTC, VirtualMaria wrote:
> On Saturday, 10 May 2014 at 09:43:46 UTC, Xavier Bigand wrote:
>>
>> Yesterday I played with my nexus 5 at a game in augmented reality, it took 2hr 20 minutes to completely drain the battery (2300 mAh). Sadly this game doesn't exist on iOS but IMO an iPhone would do the same with a smaller battery (1440 mAh for iPhone 5s).
>
> Luckily, as time passes, technologies are ready to offer us more and more. Now, VR or AR applications are available on Androis, iOS and other platforms and I would say they work similarly. I use it on iOS, but now I think about changing mobile phone and read how AR will work on Android. Multiple resources like https://www.androidauthority.com/best-augmented-reality-apps-and-ar-apps-for-android-584616/ or https://jasoren.com/how-to-create-content-for-a-vr-app/ assure me that it will function properly. I hope so!

Was confused when I saw a thread started by Andrei, then I saw the date and now it makes sense it was at a time when the iphone 5s was considered top of the line.